SEGV in glibc's _int_free(), without use of RTLD_DEEPBIND

[Zach Laine]

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

[Evgenii Stepanov]

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().

--
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 address-saniti...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/2c5d0770-7133-468f-acdf-f566e9aa8a76%40googlegroups.com.

[Evgenii Stepanov]

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.

[Zach Laine]

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

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 address-saniti...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/CAFKCwrgwpK8cx5fvZ4F3B2SD98EqSkC74%2Bfd%2Bx%2BS%2BQRVgXqP3g%40mail.gmail.com.

[Evgenii Stepanov]

On Fri, Mar 27, 2020 at 8:47 AM Zach Laine <whatwasth...@gmail.com> wrote:

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?

If you can show that this thing that is being freed has been allocated with ASan's malloc, then certainly.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/CALOpkJACBDLWQm7juPjLL1G84mUCbYhsJC1_2qo%2BTGYWrO62gw%40mail.gmail.com.

[Zach Laine]

I see now.  Thanks for clarifying that.

Zach

To view this discussion on the web visit https://groups.google.com/d/msgid/address-sanitizer/CAFKCwrhJCnm3RB3317XxJLkGy41%3DufZYC7T-EUNOv6Br_P3Q9A%40mail.gmail.com.