Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Hi Todd, Seems the problem is fixed by using parallel runner. This test exits normally after rerun. http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4357/steps/test7/logs/stdio On Thu, Dec 17, 2015 at 2:47 PM, Todd Fiala wrote: > Hi Ying, > > I just put this change in t

Re: [lldb-dev] mind if I try allowing reruns on arm/aarch64?

Yes, you could use android builder to run that experiment. Please watch test 7 of this builder after your change goes in(Another test for aarch64 which was previously timed out has been disabled for offline debugging of other unr

Re: [lldb-dev] test rerun phase is in

It also happened for -A arm. http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-android/builds/4307/steps/test7/logs/stdio On Tue, Dec 15, 2015 at 3:46 PM, Todd Fiala wrote: > Hey Ying, > > I'm going to check in something that stops the rerun logic when both (1) > -A aarch64 is specified

Re: [lldb-dev] test rerun phase is in

On Tue, Dec 15, 2015 at 3:36 PM, Todd Fiala wrote: > #4310 failed for some other reason. > Sorry for the confusion, the builds on android builders should be triggered by android buildserver , since that's where lldb-server w

Re: [lldb-dev] test rerun phase is in

Sure. Please go ahead to do that. BTW, the pending builds should be merged into one build once current build is done. On Tue, Dec 15, 2015 at 2:12 PM, Todd Fiala wrote: > Hey Ying, > > Do you mind if we clear the android builder queue to get a build with > r255676 in it? There are what looks li

Re: [lldb-dev] test rerun phase is in

Yes, it happens every time for android builder. On Tue, Dec 15, 2015 at 1:45 PM, Todd Fiala wrote: > Hmm, yeah it looks like it did the rerun and then after finishing the > rerun, it's just hanging. > > Let's have a look right after r255676 goes through this builder. I hit a > hang in the curse

Re: [lldb-dev] test rerun phase is in

Hi Todd, It is noticed on lldb android builders that the test_runner didn't exit after rerun, which caused buildbot timeout since the process was hanging for over 20 minutes. Could you please take a look if that's related to your change? Please see the following builds. http://lab.llvm.org:8011/b

Re: [lldb-dev] test rerun phase is in

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

Re: [lldb-dev] BasicResultsFormatter - new test results summary

I submitted this patch to include "ERROR" lines in buildbot step results. http://reviews.llvm.org/rL255145 Error results will be displayed in step result like this after the patch, "ERROR: 9 (SIGKILL) test_buildbot_catches_exceptional_exit_dwarf" Thanks, Ying On Wed, Dec 9, 2015 at 10:45 AM, Tod

Re: [lldb-dev] RFC: Making unit tests run by default on ninja check-lldb

an XPASS would be listed as failure. I'm not seeing us > treat XPASS as failures AFAICT. > > Are we just saying that our gtests get processed by that? > > -Todd > > On Tue, Oct 20, 2015 at 4:51 PM, Ying Chen via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > &g

Re: [lldb-dev] RFC: Making unit tests run by default on ninja check-lldb

Hi Zachary, The big unknown here is how to make the buildbots understand unit test > failures and trigger a failure when ninja check-lldb-unit fails. > There're two conditions buildbot will identity a test step as failure. One is that the command has non-zero return code. The other is that there'

Re: [lldb-dev] 7th build slot?

Thanks for the suggestions. I've changed the descriptions of "clang" to "clang-3.5" since this build. We currently have 8 test slots reserved. 1-6 are configurations that should pass, 7-8 are experimental ones that have