To me it looks like the definition of 'real_sigaction'
in 'asan_interceptors.cc' is actually going to
recursively call itself - so I tried patching
libsanitizer:
{BEGIN PATCH:
Index: asan/asan_interceptors.cc
===================================================================
--- asan/asan_interceptors.cc (revision 260441)
+++ asan/asan_interceptors.cc (working copy)
@@ -293,8 +293,8 @@
namespace __sanitizer {
int real_sigaction(int signum, const void *act, void *oldact) {
- return REAL(sigaction)(signum, (const struct sigaction *)act,
- (struct sigaction *)oldact);
+ return ::sigaction(signum, (const struct sigaction *)act,
+ (struct sigaction *)oldact);
}
} // namespace __sanitizer
Index: sanitizer_common/sanitizer_common_interceptors.inc
===================================================================
--- sanitizer_common/sanitizer_common_interceptors.inc (revision 260441)
+++ sanitizer_common/sanitizer_common_interceptors.inc (working copy)
@@ -2446,7 +2446,7 @@
INTERCEPTOR(uptr, ptrace, int request, int pid, void *addr, void *data) {
void *ctx;
COMMON_INTERCEPTOR_ENTER(ctx, ptrace, request, pid, addr, data);
- __sanitizer_iovec local_iovec;
+ __sanitizer_iovec local_iovec {};
if (data) {
if (request == ptrace_setregs)
END PATCH}
The second patch line removes a warning about local_iovec being
used uninitialized.
With the patch applied, the program does not coredump
and shows more what is going on:
$ ./pr59063-2.exe
==5898==Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.
==5898==ASan shadow was supposed to be located in the
[0x00007fff7000-0x10007fff7fff] range.
==5898==Process memory map follows:
0x000000400000-0x000000522000 /tmp/pr59063-2.exe
0x000000721000-0x000000723000 /tmp/pr59063-2.exe
0x000000723000-0x000000726000 /tmp/pr59063-2.exe
0x000000726000-0x000001398000
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
0x600000000000-0x640000000000
0x640000000000-0x640000003000
0x7f05baec2000-0x7f05bb566000
0x7f05bb566000-0x7f05bb72f000 /usr/lib64/libc-2.17.so
0x7f05bb72f000-0x7f05bb92f000 /usr/lib64/libc-2.17.so
0x7f05bb92f000-0x7f05bb933000 /usr/lib64/libc-2.17.so
0x7f05bb933000-0x7f05bb935000 /usr/lib64/libc-2.17.so
0x7f05bb935000-0x7f05bb93a000
0x7f05bb93a000-0x7f05bb950000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bb950000-0x7f05bbb4f000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb4f000-0x7f05bbb50000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb50000-0x7f05bbb51000
/home/devel/OS/gcc-6-branch/host-x86_64-linux-gnu/gcc/libgcc_s.so.1
0x7f05bbb51000-0x7f05bbb69000 /usr/lib64/libpthread-2.17.so
0x7f05bbb69000-0x7f05bbd68000 /usr/lib64/libpthread-2.17.so
0x7f05bbd68000-0x7f05bbd69000 /usr/lib64/libpthread-2.17.so
0x7f05bbd69000-0x7f05bbd6a000 /usr/lib64/libpthread-2.17.so
0x7f05bbd6a000-0x7f05bbd6e000
0x7f05bbd6e000-0x7f05bbd70000 /usr/lib64/libdl-2.17.so
0x7f05bbd70000-0x7f05bbf70000 /usr/lib64/libdl-2.17.so
0x7f05bbf70000-0x7f05bbf71000 /usr/lib64/libdl-2.17.so
0x7f05bbf71000-0x7f05bbf72000 /usr/lib64/libdl-2.17.so
0x7f05bbf72000-0x7f05bbf79000 /usr/lib64/librt-2.17.so
0x7f05bbf79000-0x7f05bc178000 /usr/lib64/librt-2.17.so
0x7f05bc178000-0x7f05bc179000 /usr/lib64/librt-2.17.so
0x7f05bc179000-0x7f05bc17a000 /usr/lib64/librt-2.17.so
0x7f05bc17a000-0x7f05bc27b000 /usr/lib64/libm-2.17.so
0x7f05bc27b000-0x7f05bc47a000 /usr/lib64/libm-2.17.so
0x7f05bc47a000-0x7f05bc47b000 /usr/lib64/libm-2.17.so
0x7f05bc47b000-0x7f05bc47c000 /usr/lib64/libm-2.17.so
0x7f05bc47c000-0x7f05bc5f6000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc5f6000-0x7f05bc7f6000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc7f6000-0x7f05bc800000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc800000-0x7f05bc802000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.22
0x7f05bc802000-0x7f05bc806000
0x7f05bc806000-0x7f05bc92f000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bc92f000-0x7f05bcb2e000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bcb2e000-0x7f05bcb31000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bcb31000-0x7f05bcb34000
/home/devel/OS/gcc-6-branch/x86_64-linux-gnu/libsanitizer/asan/.libs/libasan.so.3.0.0
0x7f05bcb34000-0x7f05bd7a6000
0x7f05bd7a6000-0x7f05bd7ca000 /usr/lib64/ld-2.17.so
0x7f05bd998000-0x7f05bd99c000
0x7f05bd9a0000-0x7f05bd9c9000
0x7f05bd9c9000-0x7f05bd9ca000 /usr/lib64/ld-2.17.so
0x7f05bd9ca000-0x7f05bd9cb000 /usr/lib64/ld-2.17.so
0x7f05bd9cb000-0x7f05bd9cc000
0x7ffc828f0000-0x7ffc82911000 [stack]
0x7ffc82984000-0x7ffc82986000 [vdso]
0xffffffffff600000-0xffffffffff601000 [vsyscall]
==5898==End of process memory map.
So:
==5898==ASan shadow was supposed to be located in the
[0x00007fff7000-0x10007fff7fff] range.
And there are existing maps in that range :
0x00007fff7000-0x00008fff7000
0x00008fff7000-0x02008fff7000
0x02008fff7000-0x10007fff8000
Could it be that somehow a link module init()
(__attribute__((constructor))) 'constructor' function in
the static libasan constructor has run. and set up the maps,
and then when dynamic libraries are loaded, the
constructor in the dynamic library tries
to construct the same maps ?
Really, I think perhaps the 'static-libasan'
option ought to be disabled until it is implemented
correctly , and/or the constructor should not be
insisting on a DT_NEEDED of libasan.so if -static-libasan
was supplied, and in any case it should be impossible to
call the constructor twice , even if the library
is loaded twice.
It looks like libasan still needs some major re-working
and I question why it is being included in the standard GCC
distribution & whether its test suite has ever passed.
Best Regards,
Jason
