Problems with ASAN builds in 7.1

[shinrich]

When running ASAN builds with the 7.1.x codebase I no longer see nice use-after-free reports (for the most part). Instead I see repeats of the following pair of lines.

{code}
==22259==ERROR: AddressSanitizer failed to deallocate 0x8000 (32768) bytes at address 0x7ffd87426000
==22259==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_posix.cc:77 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0)
{code}

Is anyone else seeing this? Any ideas on how to fix?

[zwoop]

Is this with GCC? Which version?

[shinrich]

The gcc in devtoolset-3 (gcc 4.9.2) and devtoolset-4 (gcc 5.3.1).

[shinrich]

Actually it looks like the issue is just tracking down the particular issue in #1476 / #1480.

I enabled ASAN while merging in another issue, and it caught the double free in there just fine. So I think we are good with the ASAN and I am just running into a flaw in ASAN.

[mzanini]

I am experiencing the same issue on RHEL 6.7 and devtoolset-6 (GCC 6.2.1).

==14657==ERROR: AddressSanitizer failed to deallocate 0x4000 (16384) bytes at address 0x629001220200
==14657==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_posix.cc:131 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0)
==14657==ERROR: AddressSanitizer failed to deallocate 0x4000 (16384) bytes at address 0x62900121b200
==14657==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_posix.cc:131 "(("unable to unmap" && 0)) != (0)" (0x0, 0x0)
    #0 0x33b18cb2cd  (/usr/lib64/libasan.so.3+0x33b18cb2cd)
    #1 0x33b18d0f13 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib64/libasan.so.3+0x33b18d0f13)
    #2 0x33b18dacaf  (/usr/lib64/libasan.so.3+0x33b18dacaf)
    #3 0x33b18db970  (/usr/lib64/libasan.so.3+0x33b18db970)
    #0 0x33b18cb2cd  (/usr/lib64/libasan.so.3+0x33b18cb2cd)
    #4 0x33b18ce578  (/usr/lib64/libasan.so.3+0x33b18ce578)
    #5 0x3c8ae07ae8 in start_thread (/lib64/libpthread.so.0+0x3c8ae07ae8)
    #6 0x3c8aae896c in __clone (/lib64/libc.so.6+0x3c8aae896c)

Any workaround?

[shinrich]

Sadly I am not aware of a workaround. If I run ASAN 7.x on a highly loaded system, I see this problem. With lower load, it works fine.

[bryancall]

If this is still an issue please reopen.