Bug 50995 – Flaky Test: fast/workers/storage/use-same-database-in-page-and-workers.html

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Tools / Tests

[WebKit Commit Bot]

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 [e-mail].
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.

[Eric Seidel (no email)]

*** Bug 51003 has been marked as a duplicate of this bug. ***

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[Eric Seidel (no email)]

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.

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 78608 [details]
Archive of layout-test-results from eseidel-sf-cq

[WebKit Commit Bot]

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

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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.

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 81466 [details]
Failure diff from eseidel-cq-sf

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 82344 [details]
Failure diff from eseidel-cq-sf

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 86029 [details]
Failure diff from cr-jail-3

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 86972 [details]
Failure diff from cr-jail-3

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 87261 [details]
Failure diff from cr-jail-7

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 87267 [details]
Failure diff from cr-jail-3

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 87360 [details]
Failure diff from cr-jail-8

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 87383 [details]
Failure diff from cr-jail-3

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 87776 [details]
Failure diff from cr-jail-7

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 88193 [details]
Failure diff from cr-jail-7

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 89072 [details]
Failure diff from cr-jail-3

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 91596 [details]
Failure diff from cr-jail-3

[Eric Seidel (no email)]

This seems to be failing quite often.  Any theories?

[David Levin]

Adding others who may be maintaining database related items.

[WebKit Commit Bot]

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

[WebKit Commit Bot]

Created attachment 91791 [details]
Failure diff from cr-jail-8

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[WebKit Review Bot]

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

[David Levin]

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.

[David Levin]

Looks like https://bugs.webkit.org/show_bug.cgi?id=75111 is related.

[WebKit Review Bot]

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

[Michael Nordman]

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.

[Eric Seidel (no email)]

The commit-queue forgot how to report flaky tests for several months. :)  It miraculously remembered recently.

[Michael Nordman]

(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

[Eric Seidel (no email)]

(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.

[Eric Seidel (no email)]

We may disable this feature entirely.  I'm not sure it's providing value.

[Michael Nordman]

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.

[David Levin]

(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.)

[Dmitry Lomov]

(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.

[Michael Nordman]

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.

[Hao Zheng]

(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.

[David Levin]

(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).

[Michael Nordman]

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.

[Hao Zheng]

(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.

[Hao Zheng]

(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.

[Michael Nordman]

> 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?

[Dmitry Lomov]

(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?

[Michael Nordman]

(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

[Dmitry Lomov]

(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

[Michael Nordman]

*** This bug has been marked as a duplicate of bug 75111 ***