Wink Saville via llvm-dev
2016-Sep-07 00:47 UTC
[llvm-dev] Test failures building RELEASE_3.9.0/final
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160906/468a93fc/attachment.html>
Reid Kleckner via llvm-dev
2016-Sep-07 00:54 UTC
[llvm-dev] Test failures building RELEASE_3.9.0/final
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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160906/40f87b02/attachment.html>
Eric Fiselier via llvm-dev
2016-Sep-07 00:54 UTC
[llvm-dev] Test failures building RELEASE_3.9.0/final
Almost all of the libc++ failures are due to GCC bugs. I'll work on silencing the failures but the libc++ ones are nothing to be concerned about. On Tue, Sep 6, 2016 at 6: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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160906/3f29c999/attachment.html>
Wink Saville via llvm-dev
2016-Sep-07 01:45 UTC
[llvm-dev] Test failures building RELEASE_3.9.0/final
I looked at the buildbots but I didn't archives for release builds. I was thinking I could compare my results with a buildbot version. Are there any archives for 3.9.0? On Tue, Sep 6, 2016, 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 >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160907/4633a894/attachment.html>
Wink Saville via llvm-dev
2016-Sep-07 04:56 UTC
[llvm-dev] Test failures building RELEASE_3.9.0/final
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 >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160906/4dcd57b7/attachment.html>