WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
102247
webgl-background-color.html started failing
https://bugs.webkit.org/show_bug.cgi?id=102247
Summary
webgl-background-color.html started failing
Dimitri Glazkov (Google)
Reported
2012-11-14 10:02:11 PST
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=platform%2Fchromium%2Fvirtual%2Fthreaded%2Fcompositing%2Fwebgl%2Fwebgl-background-color.html
It's hard to say why.
Attachments
Patch
(1.35 KB, patch)
2012-11-14 12:28 PST
,
James Robinson
no flags
Details
Formatted Diff
Diff
Patch for landing
(1.43 KB, patch)
2012-11-14 13:45 PST
,
James Robinson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
James Robinson
Comment 1
2012-11-14 12:28:10 PST
Created
attachment 174223
[details]
Patch
James Robinson
Comment 2
2012-11-14 12:35:53 PST
The issue here was actually a timeout due to chromium
http://src.chromium.org/viewvc/chrome?view=rev&revision=167537
. WebViewHost's d'tor navigates the page (synchronously) to about:blank:
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Tools/DumpRenderTree/chromium/WebViewHost.cpp&exact_package=chromium&q=~WebViewHost&type=cs&l=1446
one consequence of which is disabling compositing mode, which triggers this finishAllRendering() call:
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/WebKit/chromium/src/WebViewImpl.cpp&exact_package=chromium&q=WebViewImpl.cpp&type=cs&l=3946
which attempts to make a synchronous call to the compositor thread. Since the compositor thread is destroyed first, this call went nowhere and the main thread simply sat blocked until it was killed by the harness. I think the reason
http://src.chromium.org/viewvc/chrome?view=rev&revision=167537
tickled this was because of some subtleties in chromium's thread shutdown where the thread was living for longer, but I'm still tracking down exactly how this happened.
James Robinson
Comment 3
2012-11-14 12:37:36 PST
This patch also makes TestShell's behavior more similar to chrome's, where the compositor thread always outlives WebView instances.
Adrienne Walker
Comment 4
2012-11-14 12:45:56 PST
Comment on
attachment 174223
[details]
Patch R=me. This really needs a better comment.
Dimitri Glazkov (Google)
Comment 5
2012-11-14 13:32:46 PST
(In reply to
comment #4
)
> (From update of
attachment 174223
[details]
) > R=me. This really needs a better comment.
I think this change needs a meme.
James Robinson
Comment 6
2012-11-14 13:45:35 PST
Created
attachment 174246
[details]
Patch for landing
WebKit Review Bot
Comment 7
2012-11-14 14:09:45 PST
Comment on
attachment 174246
[details]
Patch for landing Clearing flags on attachment: 174246 Committed
r134667
: <
http://trac.webkit.org/changeset/134667
>
WebKit Review Bot
Comment 8
2012-11-14 14:09:49 PST
All reviewed patches have been landed. Closing bug.
Ojan Vafai
Comment 9
2012-11-14 16:15:28 PST
Is there a way to add asserts instead of just a comment?
James Robinson
Comment 10
2012-11-14 17:28:01 PST
They aren't passing yet, although I think
r134667
was a solid bug fix and should cut down on flaky crashes. There's one more race that
https://codereview.chromium.org/11363254
should fix. Leaving open until it goes green...
James Robinson
Comment 11
2012-11-15 16:40:34 PST
Fixed by
http://src.chromium.org/viewvc/chrome?view=rev&revision=168037
, removed failing expectation in
http://trac.webkit.org/changeset/134857
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug