On PowerPC and ARM (possibly, need to verify), couple tests involving
pthread_exit fail due to leaks detected by LSan. pthread_exit tries
to perform unwinding that leads to dlopen'ing libgcc_s.so. dlopen
mallocs "libgcc_s.so" string which confuses LSan, it fails to
realize that this allocation happens in dynamic linker and should
be ignored.
Symbolized leak report is required to define a suppression for this
known problem.
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
Can we fix this in a different way? The slowdown on Mac is huge, especially when not running with llvm-symbolizer but with atos.
Comment Actions
On PowerPC and ARM
If this problem only exists on PowerPC and ARM, can you perhaps keep symbolize=false on macOS?
Comment Actions
Sure, let me experiment a bit on x86 and we definitely can keep Mac without symbolization.
Comment Actions
For the context, here's the test I used:
#include <pthread.h> static void *PthreadExit(void *a) { pthread_exit(0); return 0; } int main(int argc, char** argv) { pthread_t t; pthread_create(&t, 0, PthreadExit, 0); pthread_join(t, 0); return 0; }
and here's the stack LSan reports on my ppc machine:
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x101154dc in malloc */llvm/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3 #1 0x3fffb3dddf00 in _dl_map_object_deps (*/lib64/ld64.so.2+0x1df00) #2 0x3fffb3de7b74 in dl_open_worker (*/lib64/ld64.so.2+0x27b74) #3 0x3fffb3de07f4 in _dl_catch_error (*/lib64/ld64.so.2+0x207f4) #4 0x3fffb3de7094 in _dl_open (*/lib64/ld64.so.2+0x27094) #5 0x3fffb220de94 in do_dlopen (*/lib64/libc.so.6+0x17de94) #6 0x3fffb3de07f4 in _dl_catch_error (*/lib64/ld64.so.2+0x207f4) #7 0x3fffb220e00c in __GI___libc_dlopen_mode (*/lib64/libc.so.6+0x17e00c) #8 0x3fffb2375a8c in pthread_cancel_init (*/lib64/libpthread.so.0+0x15a8c) #9 0x3fffb2375d8c in _Unwind_ForcedUnwind (*/lib64/libpthread.so.0+0x15d8c) #10 0x3fffb23729bc in __GI___pthread_unwind (*/lib64/libpthread.so.0+0x129bc) #11 0x3fffb23693e0 in __pthread_exit (*/lib64/libpthread.so.0+0x93e0) #12 0x10132448 in PthreadExit(void*) */leak_test.cc:4:3 #13 0x10123a70 in __asan::AsanThread::ThreadStart(unsigned long, __sanitizer::atomic_uintptr_t*) */llvm/llvm/projects/compiler-rt/lib/asan/asan_thread.cc:257:25 #14 0x100fa4b8 in asan_thread_start(void*) */llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:298:13 #15 0x3fffb2367da8 in start_thread (*/lib64/libpthread.so.0+0x7da8) #16 0x3fffb20be668 in __clone (*/lib64/libc.so.6+0x2e668)
The similar env and test on x86 does not report any leaks.