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
Add Michael again (who might have access to this Machine).
Tobias
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?
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
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/
I just got another error. Could we possibly disable this test until this
issue has been resolved?
Best,
Tobias
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/60 probably didn't use OS X?
I am fine if we disable it on OSX. Tsan OSX support is very new.
+Kuba, please add XFAIL for OSX.
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.
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 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.
Thank you Dmitry (and looking forward to hear at some point the story of
what actually caused this issue).
Best,
Tobias