IndexedDB: Prevent crash dereferencing null if script context has stopped
Created attachment 183227 [details] Patch
For more context, see: https://code.google.com/p/chromium/issues/detail?id=168503 https://bugs.webkit.org/show_bug.cgi?id=107050 Since the patch in 107050 didn't prevent the issue it's (probably) not a null context coming in during IDBRequest creation. Therefore the context must be getting cleared later, either by corruption or a call to stop(). Detect the latter and avoid the deference. If this works we can merge this to earlier branches and track down the root cause.
Comment on attachment 183227 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=183227&action=review OK > Source/WebCore/Modules/indexeddb/IDBRequest.cpp:443 > + // FIXME: This method not be called if stop() was previously called, but This method *should* not ...
Comment on attachment 183227 [details] Patch Another tactic is to use CRASH() to assert conditions in releases. People have done this in the past to track down unknown crashers.
Created attachment 183232 [details] Patch for landing
(In reply to comment #3) > > Source/WebCore/Modules/indexeddb/IDBRequest.cpp:443 > > + // FIXME: This method not be called if stop() was previously called, but > > This method *should* not ... Fixed. (In reply to comment #4) > (From update of attachment 183227 [details]) > Another tactic is to use CRASH() to assert conditions in releases. People have done this in the past to track down unknown crashers. Good to know - may end up using that as this investigation continues.
Comment on attachment 183232 [details] Patch for landing Clearing flags on attachment: 183232 Committed r140027: <http://trac.webkit.org/changeset/140027>
All reviewed patches have been landed. Closing bug.
Good news - this appears to have worked. Now we just need to figure out *why*.