[llvm-dev] Test failures building RELEASE_3.9.0/final

Evgenii Stepanov via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 7 11:37:43 PDT 2016


Never seen anything like this. What's the platform?


On Tue, Sep 6, 2016 at 9:56 PM, Wink Saville via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I ran "ninja check-asan" and no errors. But "ninja check-msan" had 117
> errors.
>
> I took the first FAILED test, which was for eventfd.cc, and executed the
> command
> line creating an eventfd executable in a temporary directory and then
> executed that file using gdb. Finally, used bt to dump the stack.
>
> I've emailed llvm-admin at lists.llvm.org to setup an account since
> self-registration is disable. After getting an account I'll then file a bug.
> If there's anything else anyone thinks I should do let me know.
>
> Here's the output from the FAILED test:
>
> -- Testing: 120 tests, 12 threads --
> Testing:
> FAIL: MemorySanitizer-x86_64 :: Linux/eventfd.cc (1 of 120)
> ******************** TEST 'MemorySanitizer-x86_64 :: Linux/eventfd.cc'
> FAILED ********************
> Script:
> --
> /home/wink/foss/llvm.3.9.0/build/./bin/clang --driver-mode=g++
> -fsanitize=memory -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer
> -fno-optimize-sibling-calls -m64 -gline-tables-only -O0
> /home/wink/foss/llvm.3.9.0/projects/compiler-rt/test/msan/Linux/eventfd.cc
> -o
> /home/wink/foss/llvm.3.9.0/build/projects/compiler-rt/test/msan/X86_64Config/Linux/Output/eventfd.cc.tmp
> &&
> /home/wink/foss/llvm.3.9.0/build/projects/compiler-rt/test/msan/X86_64Config/Linux/Output/eventfd.cc.tmp
> 2>&1
> --
> Exit Code: 139
>
> Command Output (stderr):
> --
> /home/wink/foss/llvm.3.9.0/build/projects/compiler-rt/test/msan/X86_64Config/Linux/Output/eventfd.cc.script:
> line 1: 29960 Segmentation fault      (core dumped)
> /home/wink/foss/llvm.3.9.0/build/projects/compiler-rt/test/msan/X86_64Config/Linux/Output/eventfd.cc.tmp
> 2>&1
>
> --
>
>
>
> And here is the compilation and gdb execution:
>
> wink at wink-desktop:~/foss/llvm.3.9.0/test-eventfd
> $ /home/wink/foss/llvm.3.9.0/build/./bin/clang --driver-mode=g++
> -fsanitize=memory -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer
> -fno-optimize-sibling-calls -m64 -gline-tables-only -O0
> /home/wink/foss/llvm.3.9.0/projects/compiler-rt/test/msan/Linux/eventfd.cc
> -o eventfd
>
> wink at wink-desktop:~/foss/llvm.3.9.0/test-eventfd
> $ gdb eventfd
> 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 eventfd...done.
> (gdb) run
> Starting program: /home/wink/foss/llvm.3.9.0/test-eventfd/eventfd
> [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 at entry=0x212c9a0 <__msan::allocator>, stat=stat at entry=0x212c970
> <__msan::fallback_allocator_cache+109392>, c=c at entry=0x2111e20
> <__msan::fallback_allocator_cache>,
>     class_id=class_id at entry=6) 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 at entry=0x212c9a0 <__msan::allocator>, stat=stat at entry=0x212c970
> <__msan::fallback_allocator_cache+109392>, c=c at entry=0x2111e20
> <__msan::fallback_allocator_cache>,
>     class_id=class_id at entry=6) at
> ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:357
> #1  0x00000000004439d7 in
> __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul,
> 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>,
> __msan::MsanMapUnmapCallback> >::Refill (this=this at entry=0x2111e20
> <__msan::fallback_allocator_cache>, allocator=allocator at entry=0x212c9a0
> <__msan::allocator>,
>     class_id=class_id at entry=6) at
> ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:1003
> #2  0x0000000000442f65 in
> __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<123145302310912ul,
> 8796093022208ul, 8ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>,
> __msan::MsanMapUnmapCallback> >::Allocate (class_id=<optimized out>,
> allocator=0x212c9a0 <__msan::allocator>, this=0x2111e20
> <__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=0x2111e20 <__msan::fallback_allocator_cache>, this=0x212c9a0
> <__msan::allocator>) at
> ../projects/compiler-rt/lib/msan/../sanitizer_common/sanitizer_allocator.h:1324
> #4  __msan::MsanAllocate (zeroise=false, alignment=8, size=82,
> stack=0x7fffffffcf10) at
> ../projects/compiler-rt/lib/msan/msan_allocator.cc:125
> #5  __msan::MsanReallocate (stack=stack at entry=0x7fffffffcf10,
> old_p=old_p at entry=0x0, new_size=new_size at entry=82,
> alignment=alignment at entry=8, zeroise=zeroise at entry=false)
>     at ../projects/compiler-rt/lib/msan/msan_allocator.cc:180
> #6  0x0000000000444bce in __interceptor_malloc (size=82) 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 0x00007ffff6c8edb1 in do_sym () from /usr/lib/libc.so.6
> #11 0x00007ffff7126014 in ?? () from /usr/lib/libdl.so.2
> #12 0x00007ffff7de93a4 in _dl_catch_error () from
> /lib64/ld-linux-x86-64.so.2
> #13 0x00007ffff7126521 in ?? () from /usr/lib/libdl.so.2
> #14 0x00007ffff7126068 in dlsym () from /usr/lib/libdl.so.2
> #15 0x000000000041983c in __interception::GetRealFunctionAddress
> (func_name=func_name at entry=0x49c9f8 "__isoc99_printf",
>     func_addr=func_addr at entry=0x2b2d8d8
> <__interception::real___isoc99_printf>, real=real at entry=4592528,
> wrapper=wrapper at entry=4592528)
>     at ../projects/compiler-rt/lib/interception/interception_linux.cc:23
> #16 0x0000000000476ecf 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 0x000000000043f935 in __msan_init () at
> ../projects/compiler-rt/lib/msan/msan.cc:386
> #19 0x0000000000446225 in __interceptor___cxa_atexit
> (func=func at entry=0x7ffff7adf010 <std::(anonymous
> namespace)::generic_error_category::~generic_error_category()>,
>     arg=arg at entry=0x7ffff7dd5b50 <std::(anonymous
> namespace)::generic_category_instance>, dso_handle=0x7ffff7dd59c0) at
> ../projects/compiler-rt/lib/msan/msan_interceptors.cc:1181
> #20 0x00007ffff7add976 in __static_initialization_and_destruction_0
> (__initialize_p=1, __priority=65535)
>     at
> /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:214
> #21 _GLOBAL__sub_I_compatibility_c__0x.cc(void) () at
> /build/gcc-multilib/src/gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:257
> #22 0x00007ffff7de94fa in call_init.part () from /lib64/ld-linux-x86-64.so.2
> #23 0x00007ffff7de960b in _dl_init () from /lib64/ld-linux-x86-64.so.2
> #24 0x00007ffff7ddadaa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
> #25 0x0000000000000001 in ?? ()
> #26 0x00007fffffffe393 in ?? ()
> #27 0x0000000000000000 in ?? ()
> (gdb)
>
>
>
> On Tue, Sep 6, 2016 at 5:54 PM, Reid Kleckner <rnk at google.com> wrote:
>>
>> These all look related to some kind of sanitizer-specific crash on
>> startup. If you're not using sanitizers, maybe you don't care about these
>> failures. If you want to file bugs and get them fixed, try running
>> 'check-asan' and 'check-msan'. Extract the failing command from a test case,
>> run it under a debugger, and file a bug with the crash stack trace. There is
>> probably some environmental issue on your system that makes shadow memory
>> allocation fail, or causes an early shadow memory access.
>>
>> On Tue, Sep 6, 2016 at 5:47 PM, Wink Saville via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>> I've "successfully" built 3.9.0 release but when I run "ninja check-all"
>>> I got 208 Unexpected failures:
>>>
>>>   Expected Passes    : 33997
>>>   Expected Failures  : 198
>>>   Unsupported Tests  : 685
>>>   Unexpected Failures: 208
>>>
>>> Below is the log I captured running "time ninja check-all | tee
>>> ninja-check-all.txt"
>>>
>>> https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA
>>>
>>> Suggestions on next steps?
>>>
>>> -- Wink
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


More information about the llvm-dev mailing list