I agree, looks like the same issue. But now it's apparently affecting Android Debug as well.. We could paper-over it by adjusting the `skip-if(Android&&!isDebugBuild)` annotation to remove the "!isDebug" restriction. But given that we've got a tight range (this particular autoland-->m-c merge), it'd be nice to see if we can figure out where/why this started perma-failing. :malexandru, one request for you: is it possible for us to backfill this testrun on Autoland and see if there's one push there where it got bad? (It doesn't look to me like we have any recent "Android 4.3" runs of any sort at all on Autoland right now, but I'm wondering if we can spawn some over the potentially-guilty range...) Also, one observation (knocking down a possible explanation): I don't think this is just a case of "rebucketing", because the logs from m-c's last good push *and* first bad push both have this identical messaging/bucket-description: ``` REFTEST INFO | Running chunk 9 out of 10 chunks. tests 3039-3417/3795 REFTEST SUITE-START | Running 379 tests REFTEST TEST-START | http://10.0.2.2:8854/tests/layout/style/crashtests/1245260-1.html ``` (Notably: exact same total number of tests, exact same range of tests (3039-3417), exact same first test name, and the problematic test does get run in both the last-good and the first-bad build (as the final test before we time out, in the latter case).
Bug 1553971 Comment 51 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I agree, looks like the same issue. But now it's apparently affecting Android Debug as well.. We could paper-over it by adjusting the `skip-if(Android&&!isDebugBuild)` annotation to remove the "!isDebug" restriction. But given that we've got a tight range (this particular autoland-->m-c merge), it'd be nice to see if we can figure out where/why this started perma-failing. :malexandru, one request for you: is it possible for us to backfill this testrun (from comment 50) on Autoland and see if there's one push there where it got bad? (It doesn't look to me like we have any recent "Android 4.3" runs of any sort at all on Autoland right now, but I'm wondering if we can spawn some over the potentially-guilty range...) Also, one observation (knocking down a possible explanation): I don't think this is just a case of "rebucketing", because the logs from m-c's last good push *and* first bad push both have this identical messaging/bucket-description: ``` REFTEST INFO | Running chunk 9 out of 10 chunks. tests 3039-3417/3795 REFTEST SUITE-START | Running 379 tests REFTEST TEST-START | http://10.0.2.2:8854/tests/layout/style/crashtests/1245260-1.html ``` (Notably: exact same total number of tests, exact same range of tests (3039-3417), exact same first test name, and the problematic test does get run in both the last-good and the first-bad build (as the final test before we time out, in the latter case).