Summary: | [chromium] worker-read-blob-async is flaky. | ||
---|---|---|---|
Product: | WebKit | Reporter: | David Levin <levin> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | dslomov, jianli, levin |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | 76503, 76756, 76942 | ||
Bug Blocks: |
Description
David Levin
2012-01-18 21:22:30 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? 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. 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.) |