[llvm-dev] greendragon build noisy due to mmap_stress.cc

25 views
Skip to first unread message

Tobias Grosser via llvm-dev

unread,
Jan 12, 2016, 3:35:48 PM1/12/16
to LLVM Dev, dvy...@google.com, Roman Gareev
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/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9532/testReport/


Dmitry Vyukov, you seem to have committed this test case back in March.
Could you possibly have a look?

CCed Michael who owns this bot (afaiu).

Best,
Tobias

---------- Forwarded message ----------
From: ** <llvm.gre...@gmail.com <mailto:llvm.gre...@gmail.com>>
Date: 2016-01-13 0:00 GMT+05:00
Subject: Clang Stage 1: cmake, RA, using system compiler (Check) - Build
# 9557 - Failure!
To: Roman Gareev <garee...@gmail.com <mailto:garee...@gmail.com>>,
Simon Atanasyan <si...@atanasyan.com <mailto:si...@atanasyan.com>>,
Teresa Johnson <tejo...@google.com <mailto:tejo...@google.com>>,
Sanjay Patel <spa...@rotateright.com <mailto:spa...@rotateright.com>>
Cc: Mikhail Zolotukhin <mzolo...@apple.com
<mailto:mzolo...@apple.com>>


__


[FAILURE] clang-stage1-cmake-RA_check [#9557]

Build URL:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9557/
Project: clang-stage1-cmake-RA_check
Date of build: Tue, 12 Jan 2016 10:37:00 -0800
Build duration: 23 min


Identified problems:

* Regression test failed: This build failed because a regression test
in the test suite FAILed. See the test report <http://testReport/>
for details.
o Indication 1

<http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA_check/9557/consoleFull#-2455948548254eaf0-7326-4999-85b0-388101f2d404>
* Ninja target failed: Below is a link to the first failed ninja target.
o Indication 1

<http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA_check/9557/consoleFull#-676809979a1ca8a51-895e-46c6-af87-ce24fa4cd561>


Tests:

Name: *AddressSanitizer-Unit*
Failed: 0 test(s), Passed: 486 test(s), Total: 486 test(s)
Name: *AddressSanitizer-i386-darwin*
Failed: 0 test(s), Passed: 345 test(s), Total: 345 test(s)
Name: *AddressSanitizer-x86_64-darwin*
Failed: 0 test(s), Passed: 345 test(s), Total: 345 test(s)
Name: *Clang*
Failed: 0 test(s), Passed: 7496 test(s), Total: 7496 test(s)
Name: *Clang Tools*
Failed: 0 test(s), Passed: 156 test(s), Total: 156 test(s)
Name: *Clang-Unit*
Failed: 0 test(s), Passed: 1385 test(s), Total: 1385 test(s)
Name: *Extra Tools Unit Tests*
Failed: 0 test(s), Passed: 73 test(s), Total: 73 test(s)
Name: *LLVM*
Failed: 0 test(s), Passed: 14153 test(s), Total: 14153 test(s)
Name: *LLVM-Unit*
Failed: 0 test(s), Passed: 1428 test(s), Total: 1428 test(s)
Name: *Profile*
Failed: 0 test(s), Passed: 25 test(s), Total: 25 test(s)
Name: *SafeStack*
Failed: 0 test(s), Passed: 7 test(s), Total: 7 test(s)
Name: *SanitizerCommon-Unit*
Failed: 0 test(s), Passed: 225 test(s), Total: 225 test(s)
Name: *SanitizerCommon-asan*
Failed: 0 test(s), Passed: 68 test(s), Total: 68 test(s)
Name: *ThreadSanitizer*
Failed: 1 test(s), Passed: 212 test(s), Total: 213 test(s)
*

* Failed: ThreadSanitizer.ThreadSanitizer.mmap_stress.cc

<http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9557/testReport/junit/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc>


*
Name: *UBSan-ASan-i386*
Failed: 0 test(s), Passed: 34 test(s), Total: 34 test(s)
Name: *UBSan-ASan-x86_64*
Failed: 0 test(s), Passed: 34 test(s), Total: 34 test(s)
Name: *UBSan-Standalone-i386*
Failed: 0 test(s), Passed: 34 test(s), Total: 34 test(s)
Name: *UBSan-Standalone-x86_64*
Failed: 0 test(s), Passed: 34 test(s), Total: 34 test(s)
Name: *UBSan-TSan-x86_64*
Failed: 0 test(s), Passed: 34 test(s), Total: 34 test(s)
Name: *cfi*
Failed: 0 test(s), Passed: 17 test(s), Total: 17 test(s)
Name: *libc++*
Failed: 0 test(s), Passed: 5023 test(s), Total: 5023 test(s)


Changes

* Commit *257497* by *spatel:*

function names start with a lower case letter ; NFC

o *edit*: llvm-revision.src/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp

* Commit *257496* by *spatel:*

function names start with a lower case letter ; NFC

o *edit*: llvm-revision.src/llvm/trunk/include/llvm/IR/IRBuilder.h
o *edit*:

llvm-revision.src/llvm/trunk/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp
o *edit*:

llvm-revision.src/llvm/trunk/lib/Transforms/InstCombine/InstCombineSelect.cpp
o *edit*:
llvm-revision.src/llvm/trunk/lib/Transforms/Utils/LoopUtils.cpp
o *edit*:

llvm-revision.src/llvm/trunk/lib/Transforms/Utils/SimplifyLibCalls.cpp
o *edit*:

llvm-revision.src/llvm/trunk/lib/Transforms/Vectorize/SLPVectorizer.cpp
o *edit*: llvm-revision.src/llvm/trunk/unittests/IR/IRBuilderTest.cpp

* Commit *257495* by *romangareev:*

We do not need to schedule another loop interchange pass after
Polly, as Polly should perform loop interchanges itself. This also
fixes a bug we see due to the "loop-interchange" pass producing
incorrect IR when compiling linpack-pc.c from the LLVM test-suite
with "-polly-position=before-vectorizer". Reviewed-by: Tobias
Grosser ____

o *edit*:
llvm-revision.src/polly/trunk/lib/CodeGen/CodegenCleanup.cpp

* Commit *257494* by *tejohnson:*

Fix bot failure from r257493: remove extraneous temp file read This
was left from an earlier version of the test.

o *edit*:

llvm-revision.src/llvm/trunk/test/Transforms/FunctionImport/funcimport_alias.ll

* Commit *257493* by *tejohnson:*

[ThinLTO] Handle an external call from an import to an alias in dest
The findExternalCalls routine ignores calls to functions already
defined in the dest module. This was not handling the case where the
definition in the current module is actually an alias to a function
call.

o *edit*:
llvm-revision.src/llvm/trunk/lib/Transforms/IPO/FunctionImport.cpp
o *add*:

llvm-revision.src/llvm/trunk/test/Transforms/FunctionImport/Inputs/funcimport_alias.ll
o *add*:

llvm-revision.src/llvm/trunk/test/Transforms/FunctionImport/funcimport_alias.ll

* Commit *257492* by *atanasyan:*

[ELF][MIPS] Do not create dynamic relocations against _gp_disp
symbol MIPS _gp_disp designates offset between start of function and
gp pointer into GOT therefore any relocations against it do not
require dynamic relocation.

o *edit*: llvm-revision.src/lld/trunk/ELF/Writer.cpp
o *edit*: llvm-revision.src/lld/trunk/test/ELF/mips-gp-disp.s

* Commit *257491* by *spatel:*

[LibCallSimplifier] use instruction-level fast-math-flags to
transform pow(exp(x)) calls See also:
http://reviews.llvm.org/rL255555 http://reviews.llvm.org/rL256871
http://reviews.llvm.org/rL256964 http://reviews.llvm.org/rL257400
http://reviews.llvm.org/rL257404 http://reviews.llvm.org/rL257414

o *edit*:

llvm-revision.src/llvm/trunk/lib/Transforms/Utils/SimplifyLibCalls.cpp
o *edit*:
llvm-revision.src/llvm/trunk/test/Transforms/InstCombine/pow-exp.ll

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Kostya Serebryany via llvm-dev

unread,
Jan 12, 2016, 4:26:20 PM1/12/16
to Tobias Grosser, LLVM Dev, Roman Gareev, Dmitry Vyukov
Hi Tobias, 

What machine is that? 
We have seen this and similar tests be flaky on older Linux kernels due to kernel bug(s). 
May I ask you to run the same test (just built with clang) on the same machine for ~100000 times and see if it ever crashes? 

clang++ ~/llvm/projects/compiler-rt/test/tsan/mmap_stress.cc -lpthread 
while true; do for((i=0;i<10;i++)); do ./a.out || echo ===============FAILED================ & done ; wait; done

Tobias Grosser via llvm-dev

unread,
Jan 12, 2016, 4:28:29 PM1/12/16
to Kostya Serebryany, LLVM Dev, Roman Gareev, Dmitry Vyukov
On 01/12/2016 10:26 PM, Kostya Serebryany wrote:
> Hi Tobias,
>
> What machine is that?
> We have seen this and similar tests be flaky on older Linux kernels due
> to kernel bug(s).
> May I ask you to run the same test (just built with clang) on the same
> machine for ~100000 times and see if it ever crashes?
>
> clang++ ~/llvm/projects/compiler-rt/test/tsan/mmap_stress.cc -lpthread
> while true; do for((i=0;i<10;i++)); do ./a.out || echo
> ===============FAILED================ & done ; wait; done

Add Michael again (who might have access to this Machine).

Tobias

Chris Matthews via llvm-dev

unread,
Jan 12, 2016, 6:23:55 PM1/12/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
I’m running this on green-dragon-03 which is running OSX 10.10.5.

/Users/buildslave/jenkins/sharedspace/clang-stage1-cmake-RA_workspace\@2/clang-build/bin/clang++ ../llvm/projects/compiler-rt/test/tsan/mmap_stress.cc -lpthread 
while true; do for((i=0;i<10;i++)); do ./a.out || echo ===============FAILED================ & done ; wait; done

Seems like it is getting about 225 runs a minute, so it will take about 8 hours to complete 100k runs.

Dmitry Vyukov via llvm-dev

unread,
Jan 13, 2016, 5:22:35 AM1/13/16
to Chris Matthews, llvm-dev, Roman Gareev, Tobias Grosser
Hi,

The test fails without output. So it either SIGSEGVs or OOM-killed. SIGSEGV can happen if mmap/pthread_create fail (probably with ENOMEM); or on first access to allocated memory if system allows overcommit.
I've added error checking to the test:

Chris Matthews via llvm-dev

unread,
Jan 13, 2016, 4:11:35 PM1/13/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
These ran to completion without error. :(

Kostya Serebryany via llvm-dev

unread,
Jan 20, 2016, 4:24:27 PM1/20/16
to Chris Matthews, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
The test fails again: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9739/testReport/junit/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc/
But unfortunately lit does not provide the original log, so we still don't know why... 

Chris Matthews via llvm-dev

unread,
Jan 20, 2016, 4:30:17 PM1/20/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
I have added a Jenkins check for this test, which explains why it fails on some builds.

Can we change the test to keep its output?  Will it just be blank anyways?

Chris Matthews via llvm-dev

unread,
Jan 20, 2016, 4:31:21 PM1/20/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
I worded that poorly, the Jenkins check I added will explain to the user that we know this fails sometimes.

Kostya Serebryany via llvm-dev

unread,
Jan 20, 2016, 4:42:17 PM1/20/16
to Chris Matthews, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
On Wed, Jan 20, 2016 at 1:31 PM, Chris Matthews <chris.m...@apple.com> wrote:
I worded that poorly, the Jenkins check I added will explain to the user that we know this fails sometimes.

On Jan 20, 2016, at 1:30 PM, Chris Matthews <chris.m...@apple.com> wrote:

I have added a Jenkins check for this test, which explains why it fails on some builds.

Can we change the test to keep its output?  Will it just be blank anyways?

The test simply prints everything to stdout. 
It's the lit driver that hides the output. 

Maybe someone with a Mac can run this test manually (with exact same build command line)
a few thousand times? I continue to suspect a kernel bug. 

Chris Matthews via llvm-dev

unread,
Jan 21, 2016, 4:20:56 PM1/21/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
The lit test directly pipes the output into the check, and does not store it in a temporary file.

Last week, I ran this test in a loop for 8 hours on a machine right after it failed in a build.  It did not reproduce.  Do you have any suggestions for reproducing?  Maybe we need to have the system under more stress before running the test?

Chris Matthews via llvm-dev

unread,
Jan 21, 2016, 4:26:48 PM1/21/16
to Christopher Matthews, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
Ah ha! I found crash reports:


green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash 
Process:               mmap_stress.cc.tmp [95010]
Path:                  /Users/USER/*/mmap_stress.cc.tmp
Identifier:            mmap_stress.cc.tmp
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        bash [95004]
User ID:               501

Date/Time:             2016-01-19 23:13:22.169 -0800
OS Version:            Mac OS X 10.10.5 (14F27)
Report Version:        11
Anonymous UUID:        DFD97AE9-5E0B-44AD-8848-A057000D1FEC


Time Awake Since Boot: 9700000 seconds

Crashed Thread:        21

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       EXC_I386_GPFLT

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib         0x00007fff98f915da syscall_thread_switch + 10
1   libsystem_platform.dylib       0x00007fff965f982d _OSSpinLockLockSlow + 63
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5e4d __sanitizer::BlockingMutex::Lock() + 29
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063db7bb __sanitizer::ThreadRegistry::CreateThread(unsigned long, bool, unsigned int, void*) + 43

Thread 1:
0   libsystem_kernel.dylib         0x00007fff98f9648a __semwait_signal + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106393a0e wrap_nanosleep + 94
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063c2bea __tsan::BackgroundThread(void*) + 346

Thread 2:
0   libsystem_kernel.dylib         0x00007fff98f9648a __semwait_signal + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395650 wrap_pthread_join + 224
2   libclang_rt.tsan_osx_dynamic.dylib 0x000000010639531a __tsan_thread_start_func + 122
3   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
4   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 3:
0   libsystem_kernel.dylib         0x00007fff98f9648a __semwait_signal + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395650 wrap_pthread_join + 224
2   libclang_rt.tsan_osx_dynamic.dylib 0x000000010639531a __tsan_thread_start_func + 122
3   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
4   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 4:
0   libsystem_kernel.dylib         0x00007fff98f915da syscall_thread_switch + 10
1   libsystem_platform.dylib       0x00007fff965f982d _OSSpinLockLockSlow + 63
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5e4d __sanitizer::BlockingMutex::Lock() + 29
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063dc076 __sanitizer::ThreadRegistry::FinishThread(unsigned int) + 22

Thread 5:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341
4   ???                            0x0000000000002009 0 + 8201

Thread 6:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341
4   ???                            0x000000000000200c 0 + 8204

Thread 7:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341
4   ???                            0x0000000000002006 0 + 8198

Thread 8:
0   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063cb015 __tsan::MetaMap::FreeRange(__tsan::ThreadState*, unsigned long, unsigned long, unsigned long) + 149

Thread 9:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341
4   ???                            0x0000000000004006 0 + 16390

Thread 10:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341
4   ???                            0x0000000000002006 0 + 8198

Thread 11:
0   libsystem_kernel.dylib         0x00007fff98f95eda __mmap + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063e0404 __sanitizer::MmapFixedNoReserve(unsigned long, unsigned long, char const*) + 100

Thread 12:
0   libsystem_kernel.dylib         0x00007fff98f95f9a __munmap + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106394fb6 wrap_munmap + 134
2   ???                            0x0000000000002000 0 + 8192

Thread 13:
0   libsystem_kernel.dylib         0x00007fff98f95eda __mmap + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063e0404 __sanitizer::MmapFixedNoReserve(unsigned long, unsigned long, char const*) + 100

Thread 14:
0   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063b8759 __tsan::CreateThreadContext(unsigned int) + 233

Thread 15:
0   libsystem_kernel.dylib         0x00007fff98f95f9a __munmap + 10
1   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5846 __sanitizer::internal_munmap(void*, unsigned long) + 6
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d6bcf __sanitizer::UnmapOrDie(void*, unsigned long) + 31
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063ba734 __tsan::MemoryRangeSet(__tsan::ThreadState*, unsigned long, unsigned long, unsigned long, unsigned long long) + 612
4   libclang_rt.tsan_osx_dynamic.dylib 0x0000000106394f20 wrap_mmap + 496
5   ???                            0x0000000000002000 0 + 8192

Thread 16:
0   libsystem_kernel.dylib         0x00007fff98f915da syscall_thread_switch + 10
1   libsystem_platform.dylib       0x00007fff965f982d _OSSpinLockLockSlow + 63
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5e4d __sanitizer::BlockingMutex::Lock() + 29
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063dc1ef __sanitizer::ThreadRegistry::StartThread(unsigned int, unsigned long, void*) + 31

Thread 17:
0   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063cb018 __tsan::MetaMap::FreeRange(__tsan::ThreadState*, unsigned long, unsigned long, unsigned long) + 152

Thread 18:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063952e5 __tsan_thread_start_func + 69
4   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
5   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 19:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063952e5 __tsan_thread_start_func + 69
4   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
5   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 20:
0   libsystem_kernel.dylib         0x00007fff98f915c2 swtch_pri + 10
1   libsystem_pthread.dylib        0x00007fff93b5d381 sched_yield + 11
2   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield() + 6
3   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063952e5 __tsan_thread_start_func + 69
4   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
5   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 21 Crashed:
0   libclang_rt.tsan_osx_dynamic.dylib 0x00000001063cbe01 wrap_OSSpinLockLock + 17
1   libsystem_pthread.dylib        0x00007fff93b5bfd7 _pthread_start + 176
2   libsystem_pthread.dylib        0x00007fff93b593ed thread_start + 13

Thread 21 crashed with X86 Thread State (64-bit):
  rax: 0x00486000000025df  rbx: 0x00000001095ea000  rcx: 0x00486000000025df  rdx: 0x0000000000000000
  rdi: 0x00007fff7d4472d8  rsi: 0x0000000000000000  rbp: 0x00000001095e9f10  rsp: 0x00000001095e9ec0
   r8: 0x00000000000028df   r9: 0x0000000000083000  r10: 0x0000000000000000  r11: 0x0000000000000206
  r12: 0x000000000000200f  r13: 0x00000000000008ff  r14: 0x00007fff7d4472d8  r15: 0x00000001063952a0
  rip: 0x00000001063cbe01  rfl: 0x0000000000010202  cr2: 0x00003100849e0000
  
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     13


Binary Images:
       0x106387000 -        0x106387ff7 +mmap_stress.cc.tmp (0) <A98F81CD-CE7F-3DD1-9C04-79A188AA7340> /Users/USER/*/mmap_stress.cc.tmp
       0x10638e000 -        0x1063fdff7 +libclang_rt.tsan_osx_dynamic.dylib (0) <D1A58E40-8472-3DFE-85F3-3E1430258010> /Users/USER/*/libclang_rt.tsan_osx_dynamic.dylib
    0x7fff69ba0000 -     0x7fff69bd6887  dyld (353.2.3) <B1B370A5-479F-3533-8AD7-97B687D4F989> /usr/lib/dyld
    0x7fff8ca26000 -     0x7fff8ca27ff7  libsystem_blocks.dylib (65) <9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1> /usr/lib/system/libsystem_blocks.dylib
    0x7fff8d4d6000 -     0x7fff8d4dbfff  libsystem_stats.dylib (163.30.2) <D0E96837-3CF6-323D-B711-6DF6F660E530> /usr/lib/system/libsystem_stats.dylib
    0x7fff8d4dc000 -     0x7fff8d4dcff7  libkeymgr.dylib (28) <77845842-DE70-3CC5-BD01-C3D14227CED5> /usr/lib/system/libkeymgr.dylib
    0x7fff8d55d000 -     0x7fff8d75746f  libobjc.A.dylib (647) <759E155D-BC42-3D4E-869B-6F57D477177C> /usr/lib/libobjc.A.dylib
    0x7fff8dab1000 -     0x7fff8dabcfff  libcommonCrypto.dylib (60061.30.1) <E789748D-F9A7-3CFF-B317-90DF348B1E95> /usr/lib/system/libcommonCrypto.dylib
    0x7fff8dd4b000 -     0x7fff8dd53ffb  libcopyfile.dylib (118.1.2) <0C68D3A6-ACDD-3EF3-991A-CC82C32AB836> /usr/lib/system/libcopyfile.dylib
    0x7fff8de1e000 -     0x7fff8de23ff7  libmacho.dylib (862) <126CA2ED-DE91-308F-8881-B9DAEC3C63B6> /usr/lib/system/libmacho.dylib
    0x7fff8e1e8000 -     0x7fff8e274fe7  libsystem_c.dylib (1044.40.1) <F0635E0F-FE4B-34DB-ACF9-A58C1E9070E9> /usr/lib/system/libsystem_c.dylib
    0x7fff8e9df000 -     0x7fff8e9e7fff  libsystem_dnssd.dylib (576.30.4) <0CEB5910-843F-315C-A1DE-5D955A48A045> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8eb0d000 -     0x7fff8eb13ff7  libsystem_networkextension.dylib (167.40.3) <BA58B30B-8377-3B0A-8AE3-4F84021D9D4E> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff8eb18000 -     0x7fff8eb1efff  libsystem_trace.dylib (72.20.1) <840F5301-B55A-3078-90B9-FEFFD6CD741A> /usr/lib/system/libsystem_trace.dylib
    0x7fff8f494000 -     0x7fff8f494ff7  libunc.dylib (29) <5676F7EA-C1DF-329F-B006-D2C3022B7D70> /usr/lib/system/libunc.dylib
    0x7fff8f513000 -     0x7fff8f515fff  libsystem_sandbox.dylib (358.20.5) <3F5E973F-C702-31AC-97BC-05F5C195683C> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff8f54d000 -     0x7fff8f55eff3  libsystem_coretls.dylib (35.40.1) <155DA0A9-2046-332E-BFA3-D7974A51F731> /usr/lib/system/libsystem_coretls.dylib
    0x7fff8f55f000 -     0x7fff8f566ff7  libcompiler_rt.dylib (35) <BF8FC133-EE10-3DA6-9B90-92039E28678F> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8fb97000 -     0x7fff8fbb3ff7  libsystem_malloc.dylib (53.30.1) <DDA8928B-CC0D-3255-BD8A-3FEA0982B890> /usr/lib/system/libsystem_malloc.dylib
    0x7fff90410000 -     0x7fff90411ff3  libSystem.B.dylib (1213) <1866C519-C5F3-3D09-8C17-A8F703664521> /usr/lib/libSystem.B.dylib
    0x7fff9195d000 -     0x7fff91985fff  libxpc.dylib (559.40.1) <5C829202-962E-3744-8B50-00D38CC88E84> /usr/lib/system/libxpc.dylib
    0x7fff928f9000 -     0x7fff9290fff7  libsystem_asl.dylib (267) <F153AC5B-0542-356E-88C8-20A62CA704E2> /usr/lib/system/libsystem_asl.dylib
    0x7fff92c13000 -     0x7fff92c16ff7  libdyld.dylib (353.2.3) <CFBBE540-D503-3AFC-B5D6-644F1E69949B> /usr/lib/system/libdyld.dylib
    0x7fff93b58000 -     0x7fff93b61fff  libsystem_pthread.dylib (105.40.1) <ACE90967-ECD0-3251-AEEB-461E3C6414F7> /usr/lib/system/libsystem_pthread.dylib
    0x7fff93b62000 -     0x7fff93b8cff7  libdispatch.dylib (442.1.4) <502CF32B-669B-3709-8862-08188225E4F0> /usr/lib/system/libdispatch.dylib
    0x7fff94527000 -     0x7fff94530ff7  libsystem_notify.dylib (133.1.1) <61147800-F320-3DAA-850C-BADF33855F29> /usr/lib/system/libsystem_notify.dylib
    0x7fff94531000 -     0x7fff94531ff7  liblaunch.dylib (559.40.1) <4F81CA3A-D2CE-3030-A89D-42F3DAD7BA8F> /usr/lib/system/liblaunch.dylib
    0x7fff94535000 -     0x7fff94539fff  libcache.dylib (69) <45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1> /usr/lib/system/libcache.dylib
    0x7fff94bd6000 -     0x7fff94bd8ff7  libsystem_coreservices.dylib (9) <41B7C578-5A53-31C8-A96F-C73E030B0938> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff965f6000 -     0x7fff965fefff  libsystem_platform.dylib (63) <64E34079-D712-3D66-9CE2-418624A5C040> /usr/lib/system/libsystem_platform.dylib
    0x7fff984d8000 -     0x7fff98551fe7  libcorecrypto.dylib (233.30.1) <5779FFA0-4D9A-3AD4-B7F2-618227621DC8> /usr/lib/system/libcorecrypto.dylib
    0x7fff98935000 -     0x7fff98936fff  libDiagnosticMessagesClient.dylib (100) <2EE8E436-5CDC-34C5-9959-5BA218D507FB> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff98f80000 -     0x7fff98f9dfff  libsystem_kernel.dylib (2782.40.9) <16AD15EF-3DAE-3F63-9D26-26CCE1920762> /usr/lib/system/libsystem_kernel.dylib
    0x7fff98fb1000 -     0x7fff98fb3fff  libquarantine.dylib (76.20.1) <7AF90041-2768-378A-925A-D83161863642> /usr/lib/system/libquarantine.dylib
    0x7fff991f1000 -     0x7fff99219fff  libsystem_info.dylib (459.40.1) <2E16C4B3-A327-3957-9C41-143911979A1E> /usr/lib/system/libsystem_info.dylib
    0x7fff9a3c0000 -     0x7fff9a3f8fff  libsystem_network.dylib (412.20.3) <6105C134-6722-3C0A-A4CE-5E1261E2E1CC> /usr/lib/system/libsystem_network.dylib
    0x7fff9a401000 -     0x7fff9a402ffb  libremovefile.dylib (35) <3485B5F4-6CE8-3C62-8DFD-8736ED6E8531> /usr/lib/system/libremovefile.dylib
    0x7fff9ab09000 -     0x7fff9ab39fff  libsystem_m.dylib (3086.1) <1E12AB45-6D96-36D0-A226-F24D9FB0D9D6> /usr/lib/system/libsystem_m.dylib
    0x7fff9ad92000 -     0x7fff9ad94fff  libsystem_configuration.dylib (699.40.2) <56F94DCE-DBDE-3615-8F07-DE6270D9F8BE> /usr/lib/system/libsystem_configuration.dylib
    0x7fff9af2a000 -     0x7fff9af55fff  libc++abi.dylib (125) <88A22A0F-87C6-3002-BFBA-AC0F2808B8B9> /usr/lib/libc++abi.dylib
    0x7fff9b2b4000 -     0x7fff9b2faff7  libauto.dylib (186) <A260789B-D4D8-316A-9490-254767B8A5F1> /usr/lib/libauto.dylib
    0x7fff9b315000 -     0x7fff9b31aff7  libunwind.dylib (35.3) <BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6> /usr/lib/system/libunwind.dylib
    0x7fff9b69d000 -     0x7fff9b6f1fff  libc++.1.dylib (120) <1B9530FD-989B-3174-BB1C-BDC159501710> /usr/lib/libc++.1.dylib
    0x7fff9c06c000 -     0x7fff9c06dfff  libsystem_secinit.dylib (18) <581DAD0F-6B63-3A48-B63B-917AF799ABAA> /usr/lib/system/libsystem_secinit.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 3447975
    thread_create: 0
    thread_set_state: 143262


System Profile:
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x10E), Broadcom BCM43xx 1.0 (7.15.166.24.3)
Bluetooth: Version 4.3.6f3 16238, 3 services, 27 devices, 1 incoming serial ports
Thunderbolt Bus: Mac mini, Apple Inc., 23.4
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453220
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x802C, 0x31364B544631473634485A2D314736453220
USB Device: Hub
USB Device: Hub
USB Device: Hub
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: IR Receiver
Serial ATA Device: APPLE SSD SM256E, 251 GB
Model: Macmini6,2, BootROM MM61.0106.B09, 4 processors, Intel Core i7, 2.6 GHz, 16 GB, SMC 2.8f1
Network Service: Ethernet, Ethernet, en0
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In

Kostya Serebryany via llvm-dev

unread,
Jan 21, 2016, 4:32:25 PM1/21/16
to Chris Matthews, Kuba Brecka, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
+kuba, who ported tsan to OSX. 

On Thu, Jan 21, 2016 at 1:26 PM, Chris Matthews <chris.m...@apple.com> wrote:
Ah ha! I found crash reports:


green-dragon-03:DiagnosticReports buildslave$ cat mmap_stress.cc.tmp_2016-01-19-231335_green-dragon-03.crash 
Process:               mmap_stress.cc.tmp [95010]
Path:                  /Users/USER/*/mmap_stress.cc.tmp
Identifier:            mmap_stress.cc.tmp
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        bash [95004]
User ID:               501

Date/Time:             2016-01-19 23:13:22.169 -0800
OS Version:            Mac OS X 10.10.5 (14F27)
Report Version:        11
Anonymous UUID:        DFD97AE9-5E0B-44AD-8848-A057000D1FEC


Time Awake Since Boot: 9700000 seconds

Crashed Thread:        21

^^^^^^^^^^^^^^^
^^^^^^^^^^^^^ 

Kuba Brecka via llvm-dev

unread,
Jan 22, 2016, 10:11:57 AM1/22/16
to Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
Hm, I tried to reproduce this as well, but unsuccessfully.  From the crash report:  EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer, in this case “0x00486000000025df”.  This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread().  So I’d say it happens when we’re dereferencing the pointer returned by cur_thread().  On OS X, we’re doing this trick where we store the ThreadState pointer in the shadow memory.  Could it be that something actually read/wrote the memory that is backed by the same place as the shadow memory?

Does “0x00486000000025df” like a reasonable content of a shadow cell?

Kuba

Dmitry Vyukov via llvm-dev

unread,
Jan 22, 2016, 10:17:39 AM1/22/16
to Kuba Brecka, llvm-dev, Roman Gareev, Tobias Grosser
On Fri, Jan 22, 2016 at 4:11 PM, Kuba Brecka <jbr...@apple.com> wrote:
> Hm, I tried to reproduce this as well, but unsuccessfully. From the crash
> report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer,
> in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17,
> which is just after the prologue and just after calling cur_thread(). So
> I’d say it happens when we’re dereferencing the pointer returned by
> cur_thread(). On OS X, we’re doing this trick where we store the
> ThreadState pointer in the shadow memory. Could it be that something
> actually read/wrote the memory that is backed by the same place as the
> shadow memory?
>
> Does “0x00486000000025df” like a reasonable content of a shadow cell?

Yes, it looks like a reasonable shadow:

// Shadow (from most significant bit):
// freed : 1
// tid : kTidBits
// is_atomic : 1
// is_read : 1
// size_log : 2
// addr0 : 3
// epoch : kClkBits

Dmitry Vyukov via llvm-dev

unread,
Jan 22, 2016, 10:54:01 AM1/22/16
to Kuba Brecka, Tobias Grosser, Nico Weber, llvm-dev, Roman Gareev
On Fri, Jan 22, 2016 at 4:17 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Fri, Jan 22, 2016 at 4:11 PM, Kuba Brecka <jbr...@apple.com> wrote:
>> Hm, I tried to reproduce this as well, but unsuccessfully. From the crash
>> report: EXC_I386_GPFLT means we’re dereferencing a non-canonical pointer,
>> in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17,
>> which is just after the prologue and just after calling cur_thread(). So
>> I’d say it happens when we’re dereferencing the pointer returned by
>> cur_thread(). On OS X, we’re doing this trick where we store the
>> ThreadState pointer in the shadow memory. Could it be that something
>> actually read/wrote the memory that is backed by the same place as the
>> shadow memory?
>>
>> Does “0x00486000000025df” like a reasonable content of a shadow cell?
>
>
>
> Yes, it looks like a reasonable shadow:
>
> // Shadow (from most significant bit):
> // freed : 1
> // tid : kTidBits
> // is_atomic : 1
> // is_read : 1
> // size_log : 2
> // addr0 : 3
> // epoch : kClkBits


+Nico pointed to another failure:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9782/testReport/ThreadSanitizer/ThreadSanitizer/mmap_stress_cc/

Nico Weber via llvm-dev

unread,
Jan 22, 2016, 3:47:14 PM1/22/16
to Dmitry Vyukov, Tobias Grosser, llvm-dev, Roman Gareev

Tobias Grosser via llvm-dev

unread,
Feb 2, 2016, 9:25:56 AM2/2/16
to Nico Weber, Dmitry Vyukov, llvm-dev, Roman Gareev
On 01/22/2016 09:47 PM, Nico Weber via llvm-dev wrote:
> Here's another one:
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60

I just got another error. Could we possibly disable this test until this
issue has been resolved?

Best,
Tobias

David Blaikie via llvm-dev

unread,
Feb 2, 2016, 11:20:25 AM2/2/16
to Tobias Grosser, llvm-dev, Roman Gareev, Nico Weber, Dmitry Vyukov
Can we XFAIL it only on OSX/Darwin & file a bug? It sounds like the issue may be restricted to that platform & there's incomplete (possibly ongoing) investigation? That way we don't risk regressing it on the platforms where this does seem to be working correctly

Nico Weber via llvm-dev

unread,
Feb 2, 2016, 11:23:17 AM2/2/16
to David Blaikie, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov

David Blaikie via llvm-dev

unread,
Feb 2, 2016, 11:25:09 AM2/2/16
to Nico Weber, Kostya Serebryany, llvm-dev, Roman Gareev, Tobias Grosser, Dmitry Vyukov
On Tue, Feb 2, 2016 at 8:23 AM, Nico Weber <tha...@google.com> wrote:

Fair point - Kostya/Dmitry, any ideas here?

Dmitry Vyukov via llvm-dev

unread,
Feb 2, 2016, 11:40:13 AM2/2/16
to David Blaikie, Kuba Brecka, llvm-dev, Roman Gareev, Tobias Grosser, Nico Weber
On Tue, Feb 2, 2016 at 5:24 PM, David Blaikie <dbla...@gmail.com> wrote:
>
>
> On Tue, Feb 2, 2016 at 8:23 AM, Nico Weber <tha...@google.com> wrote:
>>
>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
>> probably didn't use OS X?
>
>
> Fair point - Kostya/Dmitry, any ideas here?
>
>>
>>
>> On Tue, Feb 2, 2016 at 11:20 AM, David Blaikie <dbla...@gmail.com> wrote:
>>>
>>> Can we XFAIL it only on OSX/Darwin & file a bug? It sounds like the issue
>>> may be restricted to that platform & there's incomplete (possibly ongoing)
>>> investigation? That way we don't risk regressing it on the platforms where
>>> this does seem to be working correctly


I am fine if we disable it on OSX. Tsan OSX support is very new.
+Kuba, please add XFAIL for OSX.

Kuba Brecka via llvm-dev

unread,
Feb 2, 2016, 12:26:05 PM2/2/16
to Dmitry Vyukov, Tobias Grosser, Nico Weber, llvm-dev, Roman Gareev
Done in r259529.

Kuba

Dmitry Vyukov via llvm-dev

unread,
Feb 2, 2016, 12:27:19 PM2/2/16
to David Blaikie, Kuba Brecka, llvm-dev, Roman Gareev, Tobias Grosser, Nico Weber
On Tue, Feb 2, 2016 at 5:39 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Tue, Feb 2, 2016 at 5:24 PM, David Blaikie <dbla...@gmail.com> wrote:
>>
>>
>> On Tue, Feb 2, 2016 at 8:23 AM, Nico Weber <tha...@google.com> wrote:
>>>
>>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
>>> probably didn't use OS X?
>>
>>
>> Fair point - Kostya/Dmitry, any ideas here?

Ah, OK, I misread this (though, that page says 404 No Such Resource to me).

Is there any magical idea behind lit hiding test output? If mmaps are
filing with ENOMEM, then we could just stop the test of ENOMEM.

David Blaikie via llvm-dev

unread,
Feb 2, 2016, 12:50:30 PM2/2/16
to Dmitry Vyukov, Tobias Grosser, Nico Weber, llvm-dev, Roman Gareev, Kuba Brecka
On Tue, Feb 2, 2016 at 9:26 AM, Dmitry Vyukov <dvy...@google.com> wrote:
On Tue, Feb 2, 2016 at 5:39 PM, Dmitry Vyukov <dvy...@google.com> wrote:
> On Tue, Feb 2, 2016 at 5:24 PM, David Blaikie <dbla...@gmail.com> wrote:
>>
>>
>> On Tue, Feb 2, 2016 at 8:23 AM, Nico Weber <tha...@google.com> wrote:
>>>
>>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60
>>> probably didn't use OS X?
>>
>>
>> Fair point - Kostya/Dmitry, any ideas here?

Ah, OK, I misread this (though, that page says 404 No Such Resource to me).

Is there any magical idea behind lit hiding test output?

I've had some ideas about how to squirrel output back through the buildbot, etc - but would take more time/investigation than I'm likely to devote to the task any time soon, unfortunately.

In the short term/interim, you might be able to "REQUIRES: shell" and use "tee" the output to a temp file, then run FileCheck on the temp file. That way it should dump the output, then show FileCheck results after that.

Tobias Grosser via llvm-dev

unread,
Feb 3, 2016, 2:40:11 AM2/3/16
to Kuba Brecka, Dmitry Vyukov, llvm-dev, Roman Gareev, Nico Weber
On 02/02/2016 06:25 PM, Kuba Brecka via llvm-dev wrote:
> Done in r259529.

I unfortunately just got another failure, so this is clearly not darwin
only or even low-noise on none-darwin platforms:

http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9965/

I very much appreciate that people are investigating this issue, but it
would be really nice to meanwhile disable this test case.

Dmitry Vyukov via llvm-dev

unread,
Feb 3, 2016, 10:15:18 AM2/3/16
to Tobias Grosser, llvm-dev, Roman Gareev, Nico Weber
On Wed, Feb 3, 2016 at 8:40 AM, Tobias Grosser <tob...@grosser.es> wrote:
> On 02/02/2016 06:25 PM, Kuba Brecka via llvm-dev wrote:
>>
>> Done in r259529.
>
>
> I unfortunately just got another failure, so this is clearly not darwin only
> or even low-noise on none-darwin platforms:
>
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9965/
>
> I very much appreciate that people are investigating this issue, but it
> would be really nice to meanwhile disable this test case.


Disabled:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/test/tsan/mmap_stress.cc?r1=259650&r2=259649&pathrev=259650

Tobias Grosser via llvm-dev

unread,
Feb 3, 2016, 10:30:55 AM2/3/16
to Dmitry Vyukov, llvm-dev, Roman Gareev, Nico Weber
On 02/03/2016 04:14 PM, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2016 at 8:40 AM, Tobias Grosser <tob...@grosser.es> wrote:
>> On 02/02/2016 06:25 PM, Kuba Brecka via llvm-dev wrote:
>>>
>>> Done in r259529.
>>
>>
>> I unfortunately just got another failure, so this is clearly not darwin only
>> or even low-noise on none-darwin platforms:
>>
>> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9965/
>>
>> I very much appreciate that people are investigating this issue, but it
>> would be really nice to meanwhile disable this test case.
>
>
> Disabled:
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/test/tsan/mmap_stress.cc?r1=259650&r2=259649&pathrev=259650

Thank you Dmitry (and looking forward to hear at some point the story of
what actually caused this issue).

Best,
Tobias

Reply all
Reply to author
Forward
0 new messages