similar to: Flakey failure on clang-ppc64le-linux-multistage

Well, I am at my wit's end. I have copied over the script and directories for this test case and run it a few million times. First I was running one at a time, then I switched to kicking off 1000 at a time. All the while, the bots continued to run on the same machine. The script never failed even once. I am not sure if this has something to do with Python as part of llvm-lit or what is going

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

This is likely due to a race condition (%T is a shared parent directory). I'll put up a patch to fix it. On Thu, Sep 3, 2020 at 10:00 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is the machine running any jobs in parallel? Would it be worth trying running lit in the loop, rather than the script? (perhaps lit's doing something interesting) or maybe the

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at

https://llvm.org/docs/CommandGuide/lit.html already lists %T as "parent directory of %t (not unique, deprecated, do not use)". See also https://reviews.llvm.org/D35396 On Thu, Sep 3, 2020 at 3:37 PM David Blaikie <dblaikie at gmail.com> wrote: > Yeah, I think I'd be up for considering deprecation of %T due to the risk > of race conditions/conflicts between tests. %t

I think that was maybe the discussion on https://reviews.llvm.org/D78245 On Thu, Sep 3, 2020 at 6:22 PM Robinson, Paul <paul.robinson at sony.com> wrote: > I have a vague memory that libcxx wanted it for something, and claimed it > would be hard to work around not having it. > > Anyone else remember that? I can’t dredge up the details, sorry… > > In any event, a separate

Thanks everyone for this discussion. Turns out that in my effort to make it possible to run multiple instances of this script in parallel, I inadvertently hid the issue. I made each instance use a directory that has $1 appended to the name and the wrapper script provided a unique value with $LINENO. :( MaskRay, thanks for fixing the problem. All the PPC bots are back to green now. On Thu, Sep 3,

On Tue, Sep 1, 2020 at 3:57 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Sep 1, 2020 at 12:42 PM Nico Weber <thakis at chromium.org> wrote: > >> On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: >> >>> On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < >>> cfe-dev at lists.llvm.org>

This just failed again: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/1579 Bill, could you take a look at this? This is like the 3rd time I've been incorrectly pinged by this buildbot due to this issue. -- Sean Silva On Mon, Jun 13, 2016 at 8:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > Thanks for taking a look. The flaky ASan test failure in the

I threw all the sanitizers I had access to on this test and didn't find anything. The merging uses threads so I can't rule out nondeterminism. It's strange that it only happens on ppc64le and only on stage 2, so an actual miscompile wouldn't surprise me either. On Sun, Jun 12, 2016 at 4:26 PM, Sean Silva <chisophugis at gmail.com> wrote: > Also, `Clang Tools ::

Thanks for taking a look. The flaky ASan test failure in the OP was stage1 so it sounds like there may be multiple problems :( -- Sean Silva On Sun, Jun 12, 2016 at 7:32 AM, Benjamin Kramer <benny.kra at gmail.com> wrote: > I threw all the sanitizers I had access to on this test and didn't > find anything. The merging uses threads so I can't rule out > nondeterminism.

I looked at this a bit a while back when you first asked but I didn't see anything obviously wrong. Benjamin, at least one of the referenced failures was on BE powerpc64. I don't remember if that one (http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/4883) failed on stage 1 or 2 and the results pages are no longer available. BTW, I tried testing the same revision many

Hello everyone, Below are some buildbot numbers for the week of 7/10/2016 - 7/16/2016. Please see the same data in attached csv files: The longest time each builder was red during the week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed builds, failed

Hello everyone, Below are some buildbot numbers for the last week of 6/05/2016 - 6/11/2016. Thanks Galina buildername | was_red -----------------------------------------------------------+----------- sanitizer-x86_64-linux-bootstrap | 134:12:25 perf-x86_64-penryn-O3-polly-parallel-fast | 46:29:26

Hello everyone, Below are some buildbot numbers for the last week of 9/25/2016 - 10/1/2016. Please see the same data in attached csv files: The longest time each builder was red during the last week; "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green); Count of commits by project; Number of completed

Hello build bot owners! The staging master is ready. Please feel free to use it to make sure your bots would work well with the monorepo and github. The following builders could be configured to build monorepo: * clang-atom-d525-fedora-rel * clang-native-arm-lnt-perf * clang-cmake-armv7-lnt * clang-cmake-armv7-selfhost-neon * clang-cmake-armv7-quick * clang-cmake-armv7-global-isel *

Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits <cfe-commits at lists.llvm.org> wrote: > > Hello everyone, > > The staging master is

On Tue, Sep 1, 2020 at 3:32 PM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 1, 2020 at 12:07 PM Nico Weber via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> Hi, >> >> llvmbb's job is to inform people of build breaks. However, it seems to >> trigger for a big list of bots, and at least one of them seems to always be >>

I think what she is referring to was that the build seemed to be triggered by a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. the change was in llvm). I have a somewhat orthogonal but related question. In the past, commits to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this behaviour been rectified with the move to github? I am really sorry

Hi Bill, just a heads up but this bot seems to have spuriously failed on a build that only pulled in my commit r272505 which is unrelated. http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/4883 -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160612/8b2c4493/attachment.html>