Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intermittent reftest failures on linux (blank rendering) #24726

Closed
jdm opened this issue Nov 13, 2019 · 31 comments
Closed

Intermittent reftest failures on linux (blank rendering) #24726

jdm opened this issue Nov 13, 2019 · 31 comments

Comments

@jdm
Copy link
Member

@jdm jdm commented Nov 13, 2019

I've noticed this in two different pull requests since yesterday, and I'm pretty sure we've been ignoring these intermittent failures for an indeterminate amount of time. One test result looks like:
Screen Shot 2019-11-13 at 10 51 15 AM
The other test result is completely blank. This has been observed with /css/CSS2/text/text-transform-applies-to-013.xht and /css/CSS2/fonts/shand-font-002.xht so far.

@jdm jdm changed the title Intermittent font-related reftest failures on linux Intermittent reftest failures on linux (blank rendering) Nov 13, 2019
@jdm
Copy link
Member Author

@jdm jdm commented Nov 13, 2019

Observed in /css/CSS2/margin-padding-clear/margin-left-103.xht, so it's not just font-related:
Screen Shot 2019-11-13 at 3 22 29 PM

@jdm
Copy link
Member Author

@jdm jdm commented Nov 13, 2019

One theory: #24677 might have caused some layout or compositing code to believe that the window is incorrectly sized.

@jdm
Copy link
Member Author

@jdm jdm commented Nov 13, 2019

Seen in 59eca02. I haven't found any evidence of linux reftest failures before #24700 merged, so it's not completely implausible as a cultprit.

@jdm
Copy link
Member Author

@jdm jdm commented Nov 13, 2019

More specifically, #24700 did not merge (because of the reftest problem) but #24701 did which include the same changes.

@jdm
Copy link
Member Author

@jdm jdm commented Nov 13, 2019

I plan to test this theory by reverting changes since e5689df and throwing this at try-wpt many times.

@jdm jdm mentioned this issue Nov 24, 2019
1 of 3 tasks complete
bors-servo added a commit that referenced this issue Nov 25, 2019
Linux reftest investigations

Investigations for #24726.
@CYBAI CYBAI mentioned this issue Nov 27, 2019
4 of 5 tasks complete
@jdm jdm mentioned this issue Nov 27, 2019
4 of 4 tasks complete
@jdm jdm moved this from To do to In progress in Actionable intermittent failures Nov 27, 2019
@jdm
Copy link
Member Author

@jdm jdm commented Feb 15, 2020

I have a theory that this issue occurred before #24677 (which explains why it happens when we revert it) because of async webrender rendering, but #24677 wildly increased how frequently it occurs by reducing the number of steps before compositing occurs (previously there would be some messages about setting the viewport size that no longer occur). I'm going to get a revert merged and see if the frequency of the problem diminishes.

bors-servo added a commit that referenced this issue Feb 15, 2020
Revert PR that introduced frequent linux reftest failures

This should reduce the frequency of #24726.
bors-servo added a commit that referenced this issue Feb 15, 2020
Revert PR that introduced frequent linux reftest failures

This should reduce the frequency of #24726.
bors-servo added a commit that referenced this issue Feb 15, 2020
Revert PR that introduced frequent linux reftest failures

This should reduce the frequency of #24726.
bors-servo added a commit that referenced this issue Feb 21, 2020
Delay reftest screenshot while WR frame is rendering

This PR addresses the theory that #24726 occurs when WR is performing an async frame render and the reftest screenshot decides it's time to synchronously read the framebuffer. If there have not been any completed frames rendered yet, that would yield the page background colour.

The changes in this PR introduce an additional layer of synchronization - the compositor stores an AtomicBool value that indicates whether we know that a WR frame has started rendering, which is set to true when an IPC request from layout that submits a new display list is received. This bool is set to false when WR notifies us that a frame has been rendered. The screenshot code refuses to take a screenshot if the bool is true, causing us to delay taking a screenshot until there is no frame pending.
@jdm jdm mentioned this issue Feb 21, 2020
2 of 2 tasks complete
@jdm
Copy link
Member Author

@jdm jdm commented Apr 8, 2020

This was fixed by #25822.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.