[Webkit-unassigned] [Bug 90469] storage tests are flaky (crashing) on windows

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jul 3 14:04:23 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=90469





--- Comment #11 from wez at chromium.org  2012-07-03 14:04:23 PST ---
(In reply to comment #10)
> The crashes seem to start around r121610. http://trac.webkit.org/log/?verbose=on&rev=121612&stop_rev=121600 shows changes around that range. r121612 (an IDB change) would be an obvious candidate except there are crashes that occur before that change and it's pretty innocuous. (Many of the IDB crashes are in tests that don't go anywhere near cursors, either.)
> 
> http://trac.webkit.org/changeset/121610/ itself catches my eye as it is the earliest revision in all the crash blame ranges. It changes the NPAPI behavior in the ScriptController and webkit::npapi::PluginList::DebugPluginLoading on the stack is still catching my eye. Is there any chance it's running and tickling an underlying issue in the WebSQL and IndexedDB code because they are async tests that have objects that outlive the test itself?

r121610 changes the way in which the window scriptable object is protected from being leaked by badly-behaved plugins - the NPObject passed to the plugin has its reference to the underlying V8 object Dispose()d, and ignores all subsequent attempts at scripting.  From the calling plugin's point of view the behaviour should be no different from the previous NPObjectWrapper behaviour - scripting the object should simply stop working once teardown reaches a clearScriptObjects, so if the CL causes crashes then I think I must have missed a check of the underlying V8 object's validity somewhere.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list