Arch Linux

Same as  FS#50366 ?

Segfault and check fail are different things. May be they came from one bug, may be not. There are no guarantees.

I'm running into this too running the llvm "ninja check-msan" tests.

Below is the stack trace using the do nothing main and my llvm RELEASE_390/final

wink@wink-desktop:~/foss/llvm.3.9.0/test-msan
$ cat a.c
int main() {
return 0;
}
wink@wink-desktop:~/foss/llvm.3.9.0/test-msan
$ /home/wink/foss/llvm.3.9.0/build/bin/clang -fsanitize=memory -g -O0 -fno-omit-frame-pointer a.c -o a
wink@wink-desktop:~/foss/llvm.3.9.0/test-msan
$ gdb a
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a...done.
(gdb) run
Starting program: /home/wink/foss/llvm.3.9.0/test-msan/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch (
this=this@entry=0x21289a0 <__msan::allocator>, stat=stat@entry=0x2128970 <__msan::fallback_allocator_cache+109392>, c=c@entry=0x210de20 <__msan::fallback_allocator_cache>, class_id=class_id@entry=5)
at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:357
357 Batch *b = region->free_list.Pop();
(gdb) bt
#0 __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch (
this=this@entry=0x21289a0 <__msan::allocator>, stat=stat@entry=0x2128970 <__msan::fallback_allocator_cache+109392>, c=c@entry=0x210de20 <__msan::fallback_allocator_cache>, class_id=class_id@entry=5)
at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:357
#1 0x0000000000443567 in __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >::Refill (this=this@entry=0x210de20 <__msan::fallback_allocator_cache>, allocator=allocator@entry=0x21289a0 <__msan::allocator>, class_id=class_id@entry=5)
at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:1003
#2 0x0000000000442af5 in __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >::Allocate (class_id=<optimized out>, allocator=0x21289a0 <__msan::allocator>, this=0x210de20 <__msan::fallback_allocator_cache>)
at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:952
#3 __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >, __sanitizer::LargeMmapAllocator<__msan::MsanMapUnmapCallback> >::Allocate (check_rss_limit=false, cleared=false, alignment=8, size=<optimized out>, cache=0x210de20 <__msan::fallback_allocator_cache>, this=0x21289a0 <__msan::allocator>)
at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:1324
#4 __msan::MsanAllocate (zeroise=false, alignment=8, size=73, stack=0x7fffffffcea0) at ../projects/compiler-rt/lib/msan/msan_allocator.cc:125
#5 __msan::MsanReallocate (stack=stack@entry=0x7fffffffcea0, old_p=old_p@entry=0x0, new_size=new_size@entry=73, alignment=alignment@entry=8, zeroise=zeroise@entry=false)
at ../projects/compiler-rt/lib/msan/msan_allocator.cc:180
#6 0x000000000044475e in __interceptor_malloc (size=73) at ../projects/compiler-rt/lib/msan/msan_interceptors.cc:931
#7 0x00007ffff7de9161 in _dl_signal_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7de9323 in _dl_signal_cerror () from /lib64/ld-linux-x86-64.so.2
#9 0x00007ffff7de40be in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff7016db1 in do_sym () from /usr/lib/libc.so.6
#11 0x00007ffff74ae014 in ?? () from /usr/lib/libdl.so.2
#12 0x00007ffff7de93a4 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#13 0x00007ffff74ae521 in ?? () from /usr/lib/libdl.so.2
#14 0x00007ffff74ae068 in dlsym () from /usr/lib/libdl.so.2
#15 0x00000000004193cc in __interception::GetRealFunctionAddress (func_name=func_name@entry=0x499bb8 "__isoc99_printf", func_addr=func_addr@entry=0x2b298d8 <__interception::real___isoc99_printf>,
real=real@entry=4591392, wrapper=wrapper@entry=4591392) at ../projects/compiler-rt/lib/interception/interception_linux.cc:23
#16 0x0000000000476a5f in InitializeCommonInterceptors () at ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_common_interceptors.inc:5902
#17 __msan::InitializeInterceptors () at ../projects/compiler-rt/lib/msan/msan_interceptors.cc:1471
#18 0x000000000043f4c5 in __msan_init () at ../projects/compiler-rt/lib/msan/msan.cc:386
#19 0x000000000048d586 in msan.module_ctor ()
#20 0x000000000048d5dd in __libc_csu_init ()
#21 0x00007ffff6f18220 in __libc_start_main () from /usr/lib/libc.so.6
#22 0x00000000004192da in _start ()
(gdb)


Here is the output from my clang 3.8.1 as installed:

wink@wink-desktop:~/foss/llvm.3.9.0/test-msan
$ pacman -Q clang
clang 3.8.1-1
$ clang -fsanitize=memory -g -O0 -fno-omit-frame-pointer a.c -o a
wink@wink-desktop:~/foss/llvm.3.9.0/test-msan
$ gdb a
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a...done.
(gdb) run
Starting program: /home/wink/foss/llvm.3.9.0/test-msan/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000041e3b5 in __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch(__sanitizer::AllocatorStats*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >*, unsigned long) ()
(gdb) bt
#0 0x000000000041e3b5 in __sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>::AllocateBatch(__sanitizer::AllocatorStats*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >*, unsigned long) ()
#1 0x000000000041e477 in __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback> >::Refill(__sanitizer::SizeClassAllocator64<123145302310912ul, 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __msan::MsanMapUnmapCallback>*, unsigned long) ()
#2 0x000000000041d9d1 in __msan::MsanReallocate(__sanitizer::StackTrace*, void*, unsigned long, unsigned long, bool) ()
#3 0x000000000041f8fe in malloc ()
#4 0x00007ffff7de9161 in _dl_signal_error () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7de9323 in _dl_signal_cerror () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7de40be in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7016db1 in do_sym () from /usr/lib/libc.so.6
#8 0x00007ffff74ae014 in ?? () from /usr/lib/libdl.so.2
#9 0x00007ffff7de93a4 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff74ae521 in ?? () from /usr/lib/libdl.so.2
#11 0x00007ffff74ae068 in dlsym () from /usr/lib/libdl.so.2
#12 0x0000000000465c0c in __interception::GetRealFunctionAddress(char const*, unsigned long*, unsigned long, unsigned long) ()
#13 0x000000000044f5e5 in __msan::InitializeInterceptors() ()
#14 0x000000000041a305 in __msan_init ()
#15 0x0000000000485be6 in msan.module_ctor ()
#16 0x0000000000485c3d in __libc_csu_init ()
#17 0x00007ffff6f18220 in __libc_start_main () from /usr/lib/libc.so.6
#18 0x0000000000418b4a in _start ()
(gdb)

I've asked for help on the llvm-dev email list (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104643.html)

We have found a fix, see this thread (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104643.html)
for additional details. The short answer is there was a change to glibc which used malloc when loading
a dynamic library symbols. This was found and patch
(https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=24e2b1cede1952d7d4411a3cafd25dd8593dab9f) was created to
to fix it.

I've created the attached file, fix.archlinux.bug.50385.patch, which incorporates the above change and
when applied to the Arch Linux packages (https://git.archlinux.org/svntogit/packages.git) and makepkg used
to regenerate glibc the segment fault no longer occurred for me.

I thought https://reviews.llvm.org/rL269633 should be the fix on the LLVM side and is included in clang 3.9. Or is asan a different issue?