<div dir="ltr">The full set that are blowing up are:<div><br></div><div><div>=============</div><div>Issue Details</div><div>=============</div><div>FAIL: test_expr_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py)</div><div>FAIL: test_frame_variable_stripped_dwarf (lang/objc/hidden-ivars/TestHiddenIvars.py)</div><div>FAIL: test_typedef_dsym (lang/c/typedef/Testtypedef.py)</div><div>FAIL: test_typedef_dwarf (lang/c/typedef/Testtypedef.py)</div><div>FAIL: test_with_python_api_dwarf (lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py)</div><div>FAIL: test_with_python_api_dwarf (lang/objc/objc-ivar-stripped/TestObjCIvarStripped.py)</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 4:31 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm having some of these blow up.<div><br></div><div>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.</div><div><br></div><div>I'm drilling into that a bit more, that's just the first of several that fail with these changes on OS X.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 3:03 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 2:35 PM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah yes I see. Thanks, Ying (and Siva! Saw your comments too).</div><div class="gmail_extra"></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 2:34 PM, Ying Chen <span dir="ltr"><<a href="mailto:chying@google.com" target="_blank">chying@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Seems this is the first build that fails, and it only has one CL <a href="http://llvm.org/viewvc/llvm-project/?view=rev&revision=255542" style="color:rgb(68,68,68);font-family:Verdana,sans-serif;font-size:10px;text-align:center" target="_blank">255542</a>.<div><a href="http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9446" target="_blank">http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9446</a><br></div><div>I believe Zachary is looking at that problem.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 2:18 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Anybody with a fast Linux system able to take a look to see what exactly is failing there?</div><div><br></div><div>-Todd</div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 1:39 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>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.</div><div><br></div><div>The feature works like this:</div><div><br></div><div>* 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).</div><div><br></div><div>* 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.</div><div><br></div><div>* 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'll be watching the builders now and will address any issues as I see them.</div><div><br></div><div>Thanks!</div><span><font color="#888888"><div>-- <br><div><div dir="ltr">-Todd</div></div>
</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div><div class="gmail_extra">-- <br><div><div dir="ltr">-Todd</div></div>
</div></blockquote></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">-Todd</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div>