[llvm-dev] Test failures building RELEASE_3.9.0/final
Wink Saville via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 7 11:46:17 PDT 2016
Arch Linux see a little more info here
(http://lists.llvm.org/pipermail/llvm-dev/2016-September/104643.html)
On Wed, Sep 7, 2016 at 11:37 AM, Evgenii Stepanov <eugenis at google.com> wrote:
> 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