Thanks. In case it matters, I'm using GCC, and the same thing happens with and without -static-libasan.
To be 100% clear, do you agree that it is very unlikely that this is a bug fixable by changing the instrumented source code? Zach On Thu, Mar 26, 2020 at 3:39 PM 'Evgenii Stepanov' via address-sanitizer < [email protected]> wrote: > This might happen if something messed with symbol exports from the main > executable (if you are using llvm and asan runtime library is linked > statically). Things like version scripts, etc. > > On Thu, Mar 26, 2020 at 1:38 PM Evgenii Stepanov <[email protected]> > wrote: > >> It looks like free() in libc got an address that was allocated with >> ASan's malloc(). >> Yes, things like RTLD_DEEPBIND are known to cause this. >> Check how the call from #1 to #0 happened, and why did it bind to a >> libc.so symbol, and not to the asan's free(). >> >> >> On Thu, Mar 26, 2020 at 1:22 PM Zach Laine <[email protected]> >> wrote: >> >>> I'm trying to figure out if what I'm seeing is a legitimate SEGV -- that >>> is, one based on the code being instrumented -- or a crash due to a build >>> or run environment that is hostile to ASan. >>> >>> The crash is happening in our code on a call to free(), and is showing >>> up in ASan runs as a SEGV in _int_free(). The ASan-uninstrumented version >>> does not crash in this location. >>> >>> All the references to _int_free() and ASan that Googling reveals mention >>> that dlopen()-ing an .so with RTLD_DEEPBIND makes one's program >>> ASan-incompatible. I do not believe we are using dlopen() at all, but this >>> is still being investigated. The program has quite a few external >>> dependencies we need to look into. >>> >>> So, my question is: Is it possible that this _int_free() SEGV is just a >>> vanilla crash that is somehow only coming up because ASan has slightly >>> changed addresses or memory layout, etc.? >>> >>> It seems unlikely, since the usual reasons for a crash in _int_free() >>> are that the user wrote off one end of the allocated buffer being deleted, >>> or that they confused malloc/free with new/delete. As I understand it, >>> ASan should have reported either of these errors before the SEGV could have >>> happened. >>> >>> Has anyone seen this particular failure in the absence of RTLD_DEEPBIND? >>> >>> For reference, here is the actual ASan output: >>> >>> $ app-name >>> ASAN:DEADLYSIGNAL >>> ================================================================= >>> ==47276==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 >>> (pc 0x003064a78d27 bp 0x5a00000200000008 sp 0x7fff5e959740 T0) >>> #0 0x3064a78d26 in _int_free (/lib64/libc.so.6+0x3064a78d26) >>> #1 0x21914d6 in CPtrListEx::Add(void*, void*, int, int, __POSITION*) >>> (/lan/sig/cm/cds/19.00MainQt_asan/19.00.0321/tools.lnx86/bin/hyb_engd.exe+0x21914d6) >>> #2 0x216fbce in >>> CMessageFactory::RegisterPattern(CMessageFactory::tagMSGPTTN const*, >>> unsigned long) >>> (/lan/sig/cm/cds/19.00MainQt_asan/19.00.0321/tools.lnx86/bin/hyb_engd.exe+0x216fbce) >>> #3 0xbb2e14 in tagMSGFACINIT::tagMSGFACINIT() >>> ../../Modules/MessageFactory/MessageFactory.cpp:16 >>> #4 0xbb2da8 in __static_initialization_and_destruction_0 >>> ../../Modules/MessageFactory/MessageFactory.cpp:52 >>> #5 0xbb2dc3 in _GLOBAL__sub_I_MessageFactory.cpp >>> ../../Modules/MessageFactory/MessageFactory.cpp:52 >>> #6 0x9c5c97c in __libc_csu_init >>> (/lan/sig/cm/cds/19.00MainQt_asan/19.00.0321/tools.lnx86/bin/hyb_engd.exe+0x9c5c97c) >>> #7 0x3064a1ecef in __libc_start_main (/lib64/libc.so.6+0x3064a1ecef) >>> #8 0x413d54 >>> (/lan/sig/cm/cds/19.00MainQt_asan/19.00.0321/tools.lnx86/bin/hyb_engd.exe+0x413d54) >>> >>> AddressSanitizer can not provide additional info. >>> SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x3064a78d26) in >>> _int_free >>> ==47276==ABORTING >>> >>> Thanks, >>> Zach >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "address-sanitizer" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/address-sanitizer/2c5d0770-7133-468f-acdf-f566e9aa8a76%40googlegroups.com >>> <https://groups.google.com/d/msgid/address-sanitizer/2c5d0770-7133-468f-acdf-f566e9aa8a76%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "address-sanitizer" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/address-sanitizer/ujzWY45PkU0/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/address-sanitizer/CAFKCwrgwpK8cx5fvZ4F3B2SD98EqSkC74%2Bfd%2Bx%2BS%2BQRVgXqP3g%40mail.gmail.com > <https://groups.google.com/d/msgid/address-sanitizer/CAFKCwrgwpK8cx5fvZ4F3B2SD98EqSkC74%2Bfd%2Bx%2BS%2BQRVgXqP3g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/CALOpkJACBDLWQm7juPjLL1G84mUCbYhsJC1_2qo%2BTGYWrO62gw%40mail.gmail.com.
