Bug 76602 - [chromium] worker-read-blob-async is flaky.
Summary: [chromium] worker-read-blob-async is flaky.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 76503 76756 76942
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-18 21:22 PST by David Levin
Modified: 2012-01-24 15:12 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Levin 2012-01-18 21:22:30 PST
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=fast%2Ffiles%2Fworkers%2Fworker-read-blob-async.html

I did http://trac.webkit.org/changeset/105238 to help us figure this out, so now we know which assert is firing but it is unclear why the test is failing and how the assert/failure are related.

We should probably roll out r105238 when we figure this out. (Even better if we improve asserts so this type of hack wouldn't be needed.)
Comment 1 David Levin 2012-01-19 02:48:02 PST
More data, I think the line that it the exception is about is here:

http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/LayoutTests/fast/files/workers/resources/worker-apply-blob-url-to-xhr.js&l=32


This line seems clearly incorrect (now) as it calls revokeObjectURL directly instead of doing webkitURL.revokeObjectURL. There are two questions that come from this:
1. Why doesn't this exception happen everytime?
2. Why does the assert fire when this exception gets hit?
Comment 2 David Levin 2012-01-19 02:54:46 PST
More notes: This is carry over from the previous test and this issue seems to be the reason why fast/files/workers/worker-apply-blob-url-to-xhr.html is always failing.

So the console message is random depending on timing.

It could be that the assert always occurs when a url hasn't been revoked and the worker context is cleaned up but we only happen to hit this during the next test occaisionally.
Comment 3 David Levin 2012-01-19 03:20:12 PST
Another note:
It looks like DOMURL *leaks* object url's if the destructor is called and DOMURL::contextDestroyed isn't.


 (I would guess that this would be the common case because the WorkerContext should have the last ref to DOMURL and that ref should go away in ~WorkerContext which is before contextDestroyed should be called from ScriptExecutionContext.)
Comment 4 David Levin 2012-01-24 15:12:39 PST
This no longer repros but I have addressed at least two issues I found (see dependent bugs).

Also the leak is fixed but bug 74386 that fixed it has issues as noted in that bug.

So I'm resolving this one.