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 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/CAFKCwrjY%3DjEJN9hTeuu86ntiAH3JwZK1Fq_t6-hSD1bgHeASEw%40mail.gmail.com.
