1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 <2024> |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Strange problem with EPICS areaDetector |
From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
To: | Timo Korhonen <Timo.Korhonen at ess.eu> |
Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Thu, 20 Jun 2024 13:42:56 -0700 |
On 6/20/24 00:07, Timo Korhonen via Tech-talk wrote:
... "... Only activated when compiled with -O1 or higher."
Ah, my mistake. My debug build was "-O0". (and the glibc documentation[3] does not mention this) With "-O1" the s1len argument[1][2] to __strncpy_chk() is not optimized away, so that stack frame is more meaningful. I guess my advice for troubleshooting the next occurrence will include adding "OPT_CFLAGS_NO += -O1" to configure/CONFIG_SITE and rebuilding.[1] https://urldefense.us/v3/__https://github.com/bminor/glibc/blob/da905bb706672c84130226bfff9de7d6ba1f0eb6/debug/strncpy_chk.c*L23C1-L23C14__;Iw!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJhzixt4_w$ [2] https://urldefense.us/v3/__https://github.com/bminor/glibc/blob/da905bb706672c84130226bfff9de7d6ba1f0eb6/string/bits/string_fortified.h*L100-L101__;Iw!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJgZnVyUbg$ [3] https://urldefense.us/v3/__https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html__;!!G_uCfscf7eWS!fLFdio7gXAYHe7XXuSBEls_YLMUGAJgyzVCWLCwyFU3qjbvuGrndvfEfIf1_wAepl2CsuNpkJaBueVITSJgDgXBLUA$
A little bit odd is that the page also says "First enabled as -D_FORTIFY_SOURCE=2 in Ubuntu 8.10 and updated to -D_FORITFY_SOURCE=3 in Ubuntu 24.04." Apparently the update was already applied in Ubuntu 22.04. Timo On 2024-06-20, 08:52, "Tech-talk on behalf of Jörn Dreyer via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote: Hi Michael, yes, you are right that the level of optimization plays a role wether the check triggers a fault or not. At leas thats what the documentation of the _FORTIFY_SOURCE macro says. Jörn Am Donnerstag, 20. Juni 2024, 07:28:29 MESZ schrieb Michael Davidsaver via Tech-talk:On 6/19/24 21:26, Michael Davidsaver wrote:I see something like the following. All of the 'f's mean that GCC is unable to track the sizes of the objects involved. I also don't see a fault.X test.LINR ptemp=ffffffffffffffff,ffffffffffffffff papChoice=ffffffffffffffff,ffffffffffffffff i=0I spoke too soon. I can reproduce, but not with a -debug build. So I guess '-O2' vs '-O3' plays some role?X test.LINR ptemp=ffffffffffffffff,28 papChoice=ffffffffffffffff,ffffffffffffffff i=0 X test.LINR ptemp=ffffffffffffffff,0 papChoice=ffffffffffffffff,ffffffffffffffff i=1 *** buffer overflow detected ***: terminatedThe inferred size of 'ptemp' is 28 bytes, which I can only assume comes from this line.ptemp = &(pdbr_enumStrs->strs[0][0]);I don't understand why 28 and not 1, 30, or 30*40 ? The first iteration steps past this.ptemp += sizeof(pdbr_enumStrs->strs[0]);This is certainly an odd way to iterate an array...