| Summary: | [chromium] DatabaseObserver needs threadsafe fixes and other clean-up. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | David Levin <levin> | ||||||||
| Component: | WebKit Misc. | Assignee: | David Levin <levin> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | darin, dimich, dslomov, levin+threading, webkit.review.bot | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 67942 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
David Levin
2011-12-14 16:32:33 PST
Created attachment 119324 [details]
Patch
Comment on attachment 119324 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=119324&action=review > Source/WebKit/chromium/src/DatabaseObserver.cpp:90 > + m_workerLoaderProxy->postTaskForModeToWorkerContext( do we follow this style in WebKit or should it be in one long line? > LayoutTests/http/tests/workers/interrupt-database-sync-open-crash.html:8 > +var workers = new Array(30); why 30 workers and 10 iterations? Would be nice to add a comment on the number selection. Created attachment 119360 [details]
Patch for landing
Created attachment 119361 [details]
Patch for landing
Comment on attachment 119361 [details] Patch for landing Clearing flags on attachment: 119361 Committed r102894: <http://trac.webkit.org/changeset/102894> All reviewed patches have been landed. Closing bug. The test you landed with this patch is failing on Mac builds because there is no expected result. But when I put in an expected result, I get different results on different runs. It seems the output is nondeterministic. How is this supposed to work with the test machinery? (In reply to comment #7) > The test you landed with this patch is failing on Mac builds because there is no expected result. Yeah, I realized that after I landed it and then started to modify it. But I didn't realize it was causing a failure. > But when I put in an expected result, I get different results on different runs. It seems the output is nondeterministic. How is this supposed to work with the test machinery? I see. It is the exception. I should put in a handler for exceptions (since it isn't important) and causes the indeterminate output when it is unhandled. (In reply to comment #8) > (In reply to comment #7) > > The test you landed with this patch is failing on Mac builds because there is no expected result. > Yeah, I realized that after I landed it and then started to modify it. > > But I didn't realize it was causing a failure. > > > But when I put in an expected result, I get different results on different runs. It seems the output is nondeterministic. How is this supposed to work with the test machinery? > > I see. It is the exception. I should put in a handler for exceptions (since it isn't important) and causes the indeterminate output when it is unhandled. btw, I'm off tomorrow but I'm around on Tuesday. I'll see if I can fix this tomorrow night or on Tuesday. If you want a fix before then, feel free to roll out my fix and I'll land it all again with a result that is determinate. Sorry I can't handler it sooner. (In reply to comment #7) > The test you landed with this patch is failing on Mac builds because there is no expected result. But when I put in an expected result, I get different results on different runs. It seems the output is nondeterministic. How is this supposed to work with the test machinery? Skipped the test for now as I didn't figure out a quick fix (r103394). |