This is an automatically generated bug from the commit-queue. fast/workers/storage/use-same-database-in-page-and-workers.html has been flaky on the commit-queue. fast/workers/storage/use-same-database-in-page-and-workers.html was authored by dumi@chromium.org. http://trac.webkit.org/browser/trunk/LayoutTests/fast/workers/storage/use-same-database-in-page-and-workers.html The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76453 [details] on bug 50988. Bot: eseidel-cq-sl Port: Mac Platform: Mac OS X 10.6.5 The bots will update this with information from each new failure. If you would like to track this test fix with another bug, please close this bug as a duplicate.
*** Bug 51003 has been marked as a duplicate of this bug. ***
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76523 [details] on bug 51023. Bot: eseidel-cq-sl Port: Mac Platform: Mac OS X 10.6.5
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76535 [details] on bug 51037. Bot: eseidel-cq-sl Port: Mac Platform: Mac OS X 10.6.5
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76787 [details] on bug 51160. Bot: cr-jail-4 Port: Mac Platform: Mac OS X 10.6.4
This may be a timeout or crash since the cq hasn't uploaded any results for it yet. Sadly our reporting code isn't good enough at conveying that on the bug yet.
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76854 [details] on bug 51236. Bot: abarth-cq-sl Port: Mac Platform: Mac OS X 10.6.5
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 77418 [details] on bug 28291. Bot: cr-jail-4 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 77286 [details] on bug 27753. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 77330 [details] on bug 51535. Bot: eseidel-cq-sf Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 76776 [details] on bug 50971. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake while processing attachment 77591 [details] on bug 51067. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 78266 [details] on bug 52081. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 78288 [details] on bug 51982. Bot: cr-jail-4 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 77717 [details] on bug 51776. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 78408 [details] on bug 51253. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 76977 [details] on bug 51237. Bot: cr-jail-4 Port: Mac Platform: Mac OS X 10.6.4
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 78578 [details] on bug 52239. Bot: eseidel-sf-cq Port: Mac Platform: Mac OS X 10.6.4
Created attachment 78608 [details] Archive of layout-test-results from eseidel-sf-cq
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 78487 [details] on bug 50182. Bot: cr-jail-4 Port: Mac Platform: Mac OS X 10.6.4
Comment on attachment 78608 [details] Archive of layout-test-results from eseidel-sf-cq Clearly there is a bug in the zip uploading code. Investigating.
I believe the upload behavior to be fixed in http://trac.webkit.org/changeset/75583. Sorry for the noise. The next flake should give us results.
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 81231 [details] on bug 53775. Bot: eseidel-cq-sf Port: Mac Platform: Mac OS X 10.6.4
Created attachment 81466 [details] Failure diff from eseidel-cq-sf
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 82330 [details] on bug 54333. Bot: eseidel-cq-sf Port: Mac Platform: Mac OS X 10.6.4
Created attachment 82344 [details] Failure diff from eseidel-cq-sf
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 85986 [details] on bug 56414. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 86029 [details] Failure diff from cr-jail-3
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 86858 [details] on bug 57062. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 86972 [details] Failure diff from cr-jail-3
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 86935 [details] on bug 57022. Bot: cr-jail-7 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 87261 [details] Failure diff from cr-jail-7
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 87119 [details] on bug 57142. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 87267 [details] Failure diff from cr-jail-3
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 87333 [details] on bug 56602. Bot: cr-jail-8 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 87360 [details] Failure diff from cr-jail-8
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 87316 [details] on bug 57338. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 87383 [details] Failure diff from cr-jail-3
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 87712 [details] on bug 57017. Bot: cr-jail-7 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 87776 [details] Failure diff from cr-jail-7
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 88139 [details] on bug 57664. Bot: cr-jail-7 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 88193 [details] Failure diff from cr-jail-7
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 88876 [details] on bug 58143. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 89072 [details] Failure diff from cr-jail-3
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 90704 [details] on bug 53031. Bot: cr-jail-3 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 91596 [details] Failure diff from cr-jail-3
This seems to be failing quite often. Any theories?
Adding others who may be maintaining database related items.
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 91762 [details] on bug 58378. Bot: cr-jail-8 Port: Mac Platform: Mac OS X 10.6.6
Created attachment 91791 [details] Failure diff from cr-jail-8
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129530 [details] on bug 79145. Bot: ec2-cq-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129549 [details] on bug 79855. Bot: ec2-cq-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129631 [details] on bug 80004. Bot: ec2-cq-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129640 [details] on bug 80008. Bot: ec2-cq-02 Port: Chromium Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129663 [details] on bug 77522. Bot: ec2-cq-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
I think this test should just be disabled (and someone should look into it because something seems really wrong here). It is failing so much that it is getting perfectly good patches rejected from the commit queue.
Looks like https://bugs.webkit.org/show_bug.cgi?id=75111 is related.
The commit-queue just saw fast/workers/storage/use-same-database-in-page-and-workers.html flake (Text diff mismatch) while processing attachment 129688 [details] on bug 79929. Bot: ec2-cq-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
David, in recent history, is this giving us grief for v8 ports only or should we disable this test for all ports across the board? 'ChromiumXVFBPort' makes me think the former. What happened on 2012-02-29? Prior to that date, there hadn't been a report of this since 2011-04-29.
The commit-queue forgot how to report flaky tests for several months. :) It miraculously remembered recently.
(In reply to comment #60) > The commit-queue forgot how to report flaky tests for several months. :) It miraculously remembered recently. How many is several, did the amnesia start before or after 2011-04-29? And how recent is recently, revision number? This looks like something that happened on 2012-02-29 that could be related. http://trac.webkit.org/changeset/109319
(In reply to comment #61) > (In reply to comment #60) > > The commit-queue forgot how to report flaky tests for several months. :) It miraculously remembered recently. > > How many is several, did the amnesia start before or after 2011-04-29? And how recent is recently, revision number? > > This looks like something that happened on 2012-02-29 that could be related. > http://trac.webkit.org/changeset/109319 From https://bugs.webkit.org/show_activity.cgi?id=50856 it looks like the CQ forgot how to report flaky tests around last July, and started again on Valentines day.
We may disable this feature entirely. I'm not sure it's providing value.
Thnx for the dates... there's a buffer of a couple of months before amnesia set in, and a few weeks after recovery where this wasn't flaking/crashing on us. Seems like the db related patch on 2/29 may be related in some unanticipated way? I'll take a look at that patch and see if anything looks interesting. I can also take a loot at modifying the canInvokeCallback() method for this particular class &| making a custom binding for this that doesn't call CRASH (as mentioned in https://bugs.webkit.org/show_bug.cgi?id=75111) It'd probably be good to skip this test in the interim.
(In reply to comment #64) > Thnx for the dates... there's a buffer of a couple of months before amnesia set in, and a few weeks after recovery where this wasn't flaking/crashing on us. Seems like the db related patch on 2/29 may be related in some unanticipated way? > > I'll take a look at that patch and see if anything looks interesting. > > I can also take a loot at modifying the canInvokeCallback() method for this particular class &| making a custom binding for this that doesn't call CRASH (as mentioned in https://bugs.webkit.org/show_bug.cgi?id=75111) > > It'd probably be good to skip this test in the interim. Here's a better indicator for when this test fell over: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=use-same-database-in-page-and-workers.html Looks like it is only Linux and started happening http://trac.webkit.org/log/?verbose=on&rev=109304&stop_rev=109297 When a result was added for it? (Maybe not so helpful.)
(In reply to comment #65) > (In reply to comment #64) > > Thnx for the dates... there's a buffer of a couple of months before amnesia set in, and a few weeks after recovery where this wasn't flaking/crashing on us. Seems like the db related patch on 2/29 may be related in some unanticipated way? > > > > I'll take a look at that patch and see if anything looks interesting. > > > > I can also take a loot at modifying the canInvokeCallback() method for this particular class &| making a custom binding for this that doesn't call CRASH (as mentioned in https://bugs.webkit.org/show_bug.cgi?id=75111) > > > > It'd probably be good to skip this test in the interim. > > Here's a better indicator for when this test fell over: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=use-same-database-in-page-and-workers.html > > Looks like it is only Linux and started happening http://trac.webkit.org/log/?verbose=on&rev=109304&stop_rev=109297 > > When a result was added for it? (Maybe not so helpful.) Rats, it looks like the wrong result was added (without a PASS in the end). The test still times out.
Oh... that's what happened on 2/29... the results of a timed out test were added as the expected results on linux... pretty funny :) That patch should be reverted.
(In reply to comment #64) > Thnx for the dates... there's a buffer of a couple of months before amnesia set in, and a few weeks after recovery where this wasn't flaking/crashing on us. Seems like the db related patch on 2/29 may be related in some unanticipated way? > > I'll take a look at that patch and see if anything looks interesting. > > I can also take a loot at modifying the canInvokeCallback() method for this particular class &| making a custom binding for this that doesn't call CRASH (as mentioned in https://bugs.webkit.org/show_bug.cgi?id=75111) > > It'd probably be good to skip this test in the interim. I'm afraid skipping this single test is not enough. I saw that several other tests related to WebWorker flakily crash when timing out on our downstream Android bot, and all are caused by the same issue: fast/workers/worker-navigator.html = CRASH http/tests/websocket/tests/hybi/workers/close-in-worker.html = CRASH fast/workers/storage/open-database-set-empty-version-sync.html = CRASH http/tests/filesystem/workers/resolve-url.html = CRASH http/tests/websocket/tests/hybi/workers/close-in-onmessage-crash.html = CRASH We don't see other crash on public bots just because they don't timeout as frequently as on Android.
(In reply to comment #68) > > I'm afraid skipping this single test is not enough. I saw that several other tests related to WebWorker flakily crash when timing out on our downstream Android bot, and all are caused by the same issue: > fast/workers/worker-navigator.html = CRASH > http/tests/websocket/tests/hybi/workers/close-in-worker.html = CRASH > fast/workers/storage/open-database-set-empty-version-sync.html = CRASH > http/tests/filesystem/workers/resolve-url.html = CRASH > http/tests/websocket/tests/hybi/workers/close-in-onmessage-crash.html = CRASH > > We don't see other crash on public bots just because they don't timeout as frequently as on Android. At the moment, I've mostly been concerned with how this is affecting our commit queue (which is why I wanted it skipped).
Do you know if those if the proximate cause of those crashes is also a v8 binding induced CRASH() like the one in the database case? In the db case, the CRASH() call seems like an overly aggressive response to what happening in the case. > fast/workers/worker-navigator.html = CRASH > http/tests/websocket/tests/hybi/workers/close-in-worker.html = CRASH > fast/workers/storage/open-database-set-empty-version-sync.html = CRASH > http/tests/filesystem/workers/resolve-url.html = CRASH > http/tests/websocket/tests/hybi/workers/close-in-onmessage-crash.html = CRASH > > We don't see other crash on public bots just because they don't timeout as frequently as on Android. @david, seems like reverting http://trac.webkit.org/changeset/109303/ would make the cq a lot better.
(In reply to comment #69) > (In reply to comment #68) > > > > I'm afraid skipping this single test is not enough. I saw that several other tests related to WebWorker flakily crash when timing out on our downstream Android bot, and all are caused by the same issue: > > fast/workers/worker-navigator.html = CRASH > > http/tests/websocket/tests/hybi/workers/close-in-worker.html = CRASH > > fast/workers/storage/open-database-set-empty-version-sync.html = CRASH > > http/tests/filesystem/workers/resolve-url.html = CRASH > > http/tests/websocket/tests/hybi/workers/close-in-onmessage-crash.html = CRASH > > > > We don't see other crash on public bots just because they don't timeout as frequently as on Android. > > At the moment, I've mostly been concerned with how this is affecting our commit queue (which is why I wanted it skipped). Sure. Sounds good to me.
(In reply to comment #70) > Do you know if those if the proximate cause of those crashes is also a v8 binding induced CRASH() like the one in the database case? In the db case, the CRASH() call seems like an overly aggressive response to what happening in the case. Yes, I confirm.
> Yes, I confirm. The suicidal CRASH() seems too harsh for this condition. As I understand it, The c++ object has outlived it's v8 split personality (not really unexpected since the c++ obj is refcounted independently), the c++ guy tries to poke its v8 peer and CRASH() is intentionally invoked in the bindings layer as the outgoing poke is being performed. Why does that condition warrant a CRASH?
(In reply to comment #73) > > Yes, I confirm. > > The suicidal CRASH() seems too harsh for this condition. As I understand it, The c++ object has outlived it's v8 split personality (not really unexpected since the c++ obj is refcounted independently), This is definitely not expected. v8 objects maintain a "ref ptr" to c++ object. > the c++ guy tries to poke its v8 peer and CRASH() is intentionally invoked in the bindings layer as the outgoing poke is being performed. Why does that condition warrant a CRASH?
(In reply to comment #74) > (In reply to comment #73) > > > Yes, I confirm. > > > > The suicidal CRASH() seems too harsh for this condition. As I understand it, The c++ object has outlived it's v8 split personality (not really unexpected since the c++ obj is refcounted independently), > > This is definitely not expected. v8 objects maintain a "ref ptr" to c++ object. really... v8 obj goes away releasing "a" ref on the c++ guy, but not the final ref)... c++ obj still hanging around... what's not to be expected about that? See comments just added to https://bugs.webkit.org/show_bug.cgi?id=75111 about a proposed fix for this class of bugs
(In reply to comment #75) > (In reply to comment #74) > > (In reply to comment #73) > > > > Yes, I confirm. > > > > > > The suicidal CRASH() seems too harsh for this condition. As I understand it, The c++ object has outlived it's v8 split personality (not really unexpected since the c++ obj is refcounted independently), > > > > This is definitely not expected. v8 objects maintain a "ref ptr" to c++ object. > > really... v8 obj goes away releasing "a" ref on the c++ guy, but not the final ref)... c++ obj still hanging around... what's not to be expected about that? v8 objects don't go away until their C++ objects go away. We are in termination conditions here where this does not hold though. > > See comments just added to https://bugs.webkit.org/show_bug.cgi?id=75111 about a proposed fix for this class of bugs
*** This bug has been marked as a duplicate of bug 75111 ***