Heh you were skinning the same cat :-) That fixed the one I was just looking at, running the others now.
On Mon, Dec 14, 2015 at 4:42 PM, Todd Fiala <todd.fi...@gmail.com> wrote: > Yep, will try now... (I was just looking at the condition testing logic > since it looks like something isn't quite right there). > > On Mon, Dec 14, 2015 at 4:39 PM, Siva Chandra <sivachan...@google.com> > wrote: > >> Can you try again after taking my change at r255584? >> >> On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> > I'm having some of these blow up. >> > >> > In the case of test/lang/c/typedef/Testtypedef.py, it looks like some >> of the >> > @expected decorators were changed a bit, and perhaps they are not pound >> for >> > pound the same. For example, this test used to really be marked XFAIL >> (via >> > an expectedFailureClang directive), but it looks like the current >> marking of >> > compiler="clang" is either not right or not working, since the test is >> run >> > on OS X and is treated like it is expected to pass. >> > >> > I'm drilling into that a bit more, that's just the first of several that >> > fail with these changes on OS X. >> > >> > On Mon, Dec 14, 2015 at 3:03 PM, Zachary Turner <ztur...@google.com> >> wrote: >> >> >> >> I've checked in r255567 which fixes a problem pointed out by Siva. It >> >> doesn't sound related to in 255542, but looking at those logs I can't >> really >> >> tell how my CL would be related. If r255567 doesn't fix the bots, >> would >> >> someone mind helping me briefly? r255542 seems pretty >> straightforward, so I >> >> don't see why it would have an effect here. >> >> >> >> On Mon, Dec 14, 2015 at 2:35 PM Todd Fiala <todd.fi...@gmail.com> >> wrote: >> >>> >> >>> Ah yes I see. Thanks, Ying (and Siva! Saw your comments too). >> >>> >> >>> On Mon, Dec 14, 2015 at 2:34 PM, Ying Chen <chy...@google.com> wrote: >> >>>> >> >>>> Seems this is the first build that fails, and it only has one CL >> 255542. >> >>>> >> >>>> >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9446 >> >>>> I believe Zachary is looking at that problem. >> >>>> >> >>>> On Mon, Dec 14, 2015 at 2:18 PM, Todd Fiala <todd.fi...@gmail.com> >> >>>> wrote: >> >>>>> >> >>>>> I am seeing several failures on the Ubuntu 14.04 testbot, but >> >>>>> unfortunately there are a number of changes that went in at the >> same time on >> >>>>> that build. The failures I'm seeing are not appearing at all >> related to the >> >>>>> test running infrastructure. >> >>>>> >> >>>>> Anybody with a fast Linux system able to take a look to see what >> >>>>> exactly is failing there? >> >>>>> >> >>>>> -Todd >> >>>>> >> >>>>> On Mon, Dec 14, 2015 at 1:39 PM, Todd Fiala <todd.fi...@gmail.com> >> >>>>> wrote: >> >>>>>> >> >>>>>> Hi all, >> >>>>>> >> >>>>>> I just put in the single-worker, low-load, follow-up test run pass >> in >> >>>>>> r255543. Most of the work for it went in late last week, this >> just mostly >> >>>>>> flips it on. >> >>>>>> >> >>>>>> The feature works like this: >> >>>>>> >> >>>>>> * First test phase works as before: run all tests using whatever >> level >> >>>>>> of concurrency is normally used. (e.g. 8 works on an >> 8-logical-core box). >> >>>>>> >> >>>>>> * Any timeouts, failures, errors, or anything else that would have >> >>>>>> caused a test failure is eligible for rerun if either (1) it was >> marked as a >> >>>>>> flakey test via the flakey decorator, or (2) if the >> --rerun-all-issues >> >>>>>> command line flag is provided. >> >>>>>> >> >>>>>> * After the first test phase, if there are any tests that met rerun >> >>>>>> eligibility that would have caused a test failure, those get run >> using a >> >>>>>> serial test phase. Their results will overwrite (i.e. replace) >> the previous >> >>>>>> result for the given test method. >> >>>>>> >> >>>>>> The net result should be that tests that were load sensitive and >> >>>>>> intermittently fail during the first higher-concurrency test phase >> should >> >>>>>> (in theory) pass in the second, single worker test phase when the >> test suite >> >>>>>> is only using a single worker. This should make the test suite >> generate >> >>>>>> fewer false positives on test failure notification, which should >> make >> >>>>>> continuous integration servers (testbots) much more useful in >> terms of >> >>>>>> generating actionable signals caused by version control changes to >> the lldb >> >>>>>> or related sources. >> >>>>>> >> >>>>>> Please let me know if you see any issues with this when running the >> >>>>>> test suite using the default output. I'd like to fix this up >> ASAP. And for >> >>>>>> those interested in the implementation, I'm happy to do post-commit >> >>>>>> review/changes as needed to get it in good shape. >> >>>>>> >> >>>>>> I'll be watching the builders now and will address any issues as I >> >>>>>> see them. >> >>>>>> >> >>>>>> Thanks! >> >>>>>> -- >> >>>>>> -Todd >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> -Todd >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> -Todd >> > >> > >> > >> > >> > -- >> > -Todd >> > >> > _______________________________________________ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > >> > > > > -- > -Todd > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
