Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50385 - [clang] fsanitize=memory Segmenation fault

Attached to Project: Arch Linux
Opened by Marat Kagarmanov (corvinusz) - Saturday, 13 August 2016, 17:11 GMT
Last edited by Evangelos Foutras (foutrelis) - Thursday, 27 October 2016, 19:44 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Evangelos Foutras (foutrelis)
Bartłomiej Piotrowski (Barthalion)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description: Segmentation fault if compiled with sanitizer.

Additional info:
$ pacman -Q clang clang-tools-extra gcc gcc-libs
clang 3.8.1-1
clang-tools-extra 3.8.1-1
gcc 6.1.1-5
gcc-libs 6.1.1-5

Always mentioned at https://github.com/golang/go/issues/16636 (with logs, dumps and gdb output)

Steps to reproduce:
$ cat > a.c
int main() {
return 0;
}
$ clang -fsanitize=memory -o a a.c
$ ./a
Segmentation fault
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Thursday, 27 October 2016, 19:44 GMT
Reason for closing:  Fixed
Additional comments about closing:  clang 3.9.0-1
Comment by Doug Newgard (Scimmia) - Saturday, 13 August 2016, 23:18 GMT
Same as  FS#50366 ?
Comment by Marat Kagarmanov (corvinusz) - Sunday, 14 August 2016, 02:39 GMT
Segfault and check fail are different things. May be they came from one bug, may be not. There are no guarantees.
Comment by Wink Saville (winksaville) - Wednesday, 07 September 2016, 16:37 GMT
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)


Comment by Wink Saville (winksaville) - Wednesday, 07 September 2016, 17:45 GMT
I've asked for help on the llvm-dev email list (http://lists.llvm.org/pipermail/llvm-dev/2016-September/104643.html)
Comment by Wink Saville (winksaville) - Tuesday, 13 September 2016, 01:31 GMT
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.
Comment by Hexcles Ma (bob.robot) - Sunday, 25 September 2016, 14:07 GMT
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?

Loading...