similar to: [LLVMdev] [PATCH] Test failures

This morning I'm seeing 4 new sanitizer failures in SanitizerCommon-Unit (compared to a couple of days ago, when I didn't see these) - perhaps related to recent library refactoring? SanitizerCommon-Unit :: Sanitizer-i386-Test/DeadlockDetector.RemoveEdgesTest SanitizerCommon-Unit :: Sanitizer-i386-Test/SanitizerCommon.ThreadRegistryTest SanitizerCommon-Unit ::

Hi, I'm seeming new regressions form 4.0.0 for mips big endian: DataFlowSanitizer-mips64 :: custom.cc DataFlowSanitizer-mips64 :: propagate.c SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard-dso.cc SanitizerCommon-asan-mips-Linux :: sanitizer_coverage_trace_pc_guard.cc SanitizerCommon-asan-mips64-Linux :: Linux/getpwnam_r_invalid_user.cc

On Friday, July 31, 2015 07:50 AM, Hans Wennborg wrote: > Dear testers, > > 3.7.0-rc2 was just tagged. Please test, build binaries, upload to the > sftp, and report results to this thread. LNT is looking good on Ubuntu 14.04 x64, uploaded: clang+llvm-3.7.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz The errors reported during build are: Failing Tests (17):

64bit Fedora Failing Tests (8): LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc LeakSanitizer-AddressSanitizer :: TestCases/disabler_in_tsd_destructor.cc LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc

> Ben reports that he didn't get a tarball even after the rpath fix and > had to disable -o pipefail to get one. Still not sure what caused > this. 'make check' failures can cause this. I had to revert r241599 to get a package. > Appendix: compiler-rt test failures > =================================== > Just to add Mips to this: On big-endian Mips32r2:

clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) Native: All ok Cross compiling to MIPS: All ok clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) All ok (aside from non-regression failures in check-all). There were two kinds of check-all failure: * mips64 sanitizers. Not a regression since

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 2dedc6136d7cfbac8348652c543887964d92393c) > Native: All ok > Cross compiling to MIPS: All ok > > clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: f286149dbb2ea7e194c5c3719b6cded476f6e65f) > All ok

Different, but still failing (this time with Xcode 4.4…) /Users/rrelph/llvm/tot/xcode/bin/Debug/clang sanitizer_allocator_test.cc.i386.o sanitizer_common_test.cc.i386.o sanitizer_flags_test.cc.i386.o sanitizer_libc_test.cc.i386.o sanitizer_list_test.cc.i386.o sanitizer_printf_test.cc.i386.o sanitizer_stackdepot_test.cc.i386.o sanitizer_test_main.cc.i386.o gtest-all.cc.i386.o

Some updates: First, thanks so much for creating these test suites. Troubleshooting is going very quickly! > There is some flakiness in SanitizerCommon.SpinMutex test. Yes, I'm seeing that too. SpinMutexTry as well. Should these be disabled? > ARM JellyBean works over here. I found a configuration that works well on JB 4.1.2 and 4.2.2. The trick is to build the ASan *runtime*

On Fri, Oct 18, 2013 at 3:27 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Some updates: > > First, thanks so much for creating these test suites. Troubleshooting > is going very quickly! > > > > There is some flakiness in SanitizerCommon.SpinMutex test. > > Yes, I'm seeing that too. SpinMutexTry as well. Should these be disabled? > There is an

ARM JellyBean works over here. There is some flakiness in SanitizerCommon.SpinMutex test. On Wed, Oct 16, 2013 at 11:36 PM, Greg Fitzgerald <garious at gmail.com> wrote: > I'm following these instructions with the latest code from llvm.org: > > > https://code.google.com/p/address-sanitizer/source/browse/trunk/build/scripts/slave/buildbot_cmake.sh > > Of

> We have plans to actually compile the symbolizer into the binary and do > in-process symbolization, but it's not there yet. nice! > I'm confused here. compiler-rt and clang/llvm instrumentation depend on each other These two projects don't need to be interdependent and, for the most part, they aren't. In the same way that llvm does not depend on clang, compiler-rt

Hi Richard! On Thu, Dec 20, 2012 at 12:48 AM, Nick Kledzik <kledzik at apple.com> wrote: > Those look like the linker is being passed the same .o file built twice, > ex: > ../Objects-normal/x86_64/asan_globals_test.o > ../lib/asan/tests/asan_globals_test.cc.asan.o > > So, the symbols are colliding. Something is set up wrong in the xcode > project. > > -Nick

Hi, one of the greendragon bots is flaky due to mmap_stress.cc in compiler-rt. In the last two days this bot failed three times (and recovered) due to thhe mmap_stress.cc test in compiler-rt: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9557/testReport/ http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9551/testReport/

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Hello everyone, 9.0.0-rc5 was just tagged from the release_90 branch at r371837. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc5. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc5 Binaries will be added as they become available. There is only a single change from rc4 to rc5. Once more, the hope is that this will be the last release candidate and that we can

Hi, I've just tagged LLVM 9.0.1-rc3. Testers can begin testing and uploading binaries. This will be the last release candidate unless there is a major problem. I'm planning to tag the final release on Dec 19. -Tom

Hello again, 9.0.0-rc4 was just tagged from the release_90 branch at r371490. In the Git monorepo, it's tagged as llvmorg-9.0.0-rc4. Source code and docs are available at https://prereleases.llvm.org/9.0.0/#rc4 Binaries will be added as they become available. There are not a lot of changes from rc3 to rc4, and there are again no open release blockers, so I'm hoping this will be the last

Hi, I've tagged the LLVM 9.0.1-rc1 release. Testers can begin testing and upload binaries. I've also updated the test-release.sh script to pull from GitHub instead of SVN, if you run into any issues with the new script, let me know. -Tom