Closed Bug 738652 Opened 13 years ago Closed 13 years ago

Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad, testPanCorrectness (and others?) (Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0))

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
All
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-fennec1.0 -)

Status:
RESOLVED DUPLICATE of bug 767215
Tracking Flags:
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: kats, Unassigned)

Details

The various pixel-checking tests (testLoad, testPanCorrectness, test_bug720538, testOverscroll, testAxisLocking) are intermittently failing with the error: Pixel at 0, 0 - Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0) This seems to have first occurred on inbound with cset https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=636349fa2e09 (bug 735378) but has continued to occur intermittently even after that cset was backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/53c21294270d. The errors are sometimes mixed with the testAboutPage failures (bug 738645) Example logs: https://tbpl.mozilla.org/php/getParsedLog.php?id=10296760&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=10296278&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=10296014&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=10299320&tree=Mozilla-Inbound .. and so on.
I am trying to figure this out in order to land my reuse the profile patch. I get this for all the pixelbase tests. I assumed it was my profile, but maybe it is something else.
Oh, weird. I wasn't seeing it at all when I ran the tests locally. Ping me on IRC if you need any help. The first place I would start looking (assuming the robocop_boxes file shows up correctly on the screen while the test is running) is the pixels.map file after a failure to see if it is just all white or has the right box data.
One patch that went in a bit before this started cropping up was bug 738137, which could potentially affect layers rendering on android.
https://tbpl.mozilla.org/php/getParsedLog.php?id=10324205&tree=Mozilla-Inbound
Summary: Robocop: intermittent failures with the pixel tests → Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad (and others?)
https://tbpl.mozilla.org/php/getParsedLog.php?id=10324137&tree=Firefox https://tbpl.mozilla.org/php/getParsedLog.php?id=10324205&tree=Mozilla-Inbound
Summary: Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad (and others?) → Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad (and others?) (Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0))
https://tbpl.mozilla.org/php/getParsedLog.php?id=10339360&tree=Mozilla-Inbound
Summary: Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad (and others?) (Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0)) → Robocop: intermittent failures with the pixel tests in testAxisLocking, test_bug720538, testOverscroll, testLoad, testPanCorrectness (and others?) (Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0))
(In reply to Jeff Gilbert [:jgilbert] from comment #3) > One patch that went in a bit before this started cropping up was bug 738137, > which could potentially affect layers rendering on android. I reverted this patch and pushed to try (https://tbpl.mozilla.org/?tree=Try&rev=ec67fa0ff392) to see if that fixes it. Unfortunately at least one of the runs has a testAxisLocking failure, so it seems like reverting that alone isn't enough to do the trick.
I triggered some more robocop runs on inbound prior to cset 636349fa2e09 and this failure never seems to show up. My current hypothesis is that it is caused by both 636349fa2e09 (bug 735378) and 017f6dd98dc0 (bug 725428) and am doing a try run with the latest versions of both of those backed out together. (They've both been backed out and re-landed on inbound, but they were never both backed out at the same time). Try run for all y'all to follow along with baited breath: https://tbpl.mozilla.org/?tree=Try&rev=af0aceba2a42
blocking-fennec1.0: --- → -
(In reply to Kartikaya Gupta (:kats) from comment #43) > I triggered some more robocop runs on inbound prior to cset 636349fa2e09 and > this failure never seems to show up. My current hypothesis is that it is > caused by both 636349fa2e09 (bug 735378) and 017f6dd98dc0 (bug 725428) and > am doing a try run with the latest versions of both of those backed out > together. (They've both been backed out and re-landed on inbound, but they > were never both backed out at the same time). > > Try run for all y'all to follow along with baited breath: > https://tbpl.mozilla.org/?tree=Try&rev=af0aceba2a42 That didn't work, there were still some failures. Not sure what the problem is, as I can't reproduce this locally. jmaher, if you can reproduce, can you attach a pixels.map file from a failed run?
With various try pushes, I managed to determine that the actual pixel data we're getting is all white, so this isn't just a bug in the testing setup. It's an actual bug that should be fixed rather than hidden. I also managed to (I think) see this happen on my device a couple of times while doing checkerboard testing - the page would "load" but the screen would remain white. I didn't have extra debugging info in the logcat when it happened, but based on what was already in the log it seemed like the setFirstPaintViewport wasn't getting called when it should have. Not yet sure why this didn't happen, but now I have a build with more logging to try and isolate this. I can't just throw it on try because try doesn't give useful logcat output so I have to run it locally a bajillion times until I see it again.
(In reply to TinderboxPushlog Robot from comment #125) > edmorley > https://tbpl.mozilla.org/php/getParsedLog.php?id=10998054&tree=Mozilla- > Inbound > Android Tegra 250 mozilla-inbound opt test robocop on 2012-04-17 23:49:12 > slave: tegra-244 > > 4 INFO TEST-UNEXPECTED-FAIL | test_bug720538 | Checking page background to > the left of the iframe - Color rgba(0,0,255,255) not close enough to > expected rgb(0,128,0) This (and all subsequent reports where it says 0,0,255,255 not close enough to 0,128,0) is a new failure. It appears to be a regression from my patch https://hg.mozilla.org/integration/mozilla-inbound/rev/17d247638c4b (bug 743800). I will file a new bug for it.
Filed bug 746876 for the new issue as described in my previous comment. In fact, the original issue this bug was opened for hasn't happened for 2 weeks, and I think has been fixed somewhere along the way. I'm going to mark this bug closed. Please reopen only if the original signature ("(Color rgba(255,255,255,255) not close enough to expected rgb(0,0,0))") shows up in future failures, for other failures please open a new bug.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The last two failures listed above on the profiling branch happen just before 767215 was pulled over from m-c. Since 767215 landed there haven't been any failures.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → DUPLICATE
Whiteboard: [orange]
No longer blocks: 438871
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.