[Webkit-unassigned] [Bug 94235] New: IndexedDB: IDBRequest can be GCd during event dispatch

[bugzilla-daemon at webkit.org]

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

           Summary: IndexedDB: IDBRequest can be GCd during event dispatch
           Product: WebKit
           Version: 523.x (Safari 3)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: jsbell at chromium.org
                CC: dgrogan at chromium.org, alecflett at chromium.org


This may be V8/Chromium and possibly Worker specific.

Repro is at: http://crbug.com/142419

Scenario:

* Build up a lot of garbage in script
* Iterate a cursor using syntax like this:

store.openCursor(lo, hi).onsuccess = function(e) {
  var cursor = e.target.result;
  if (cursor) {
    cursor.continue();
  }
};

* Since there is no reference to the IDBRequest returned by openCursor() it can be reclaimed. 

There is logic in IDBRequest::hasPendingActivity() to prevent this, which tests:

  m_readyState·==·PENDING·||·ActiveDOMObject::hasPendingActivity()

But m_readyState is set to DONE at the start of IDBRequest::dispatchEvent(), so when the dispatch actually occurs and we dive into script, GC can kick in before the listener function is called and request can be GC'd on the script side of things.

A trivial fix is to add m_isDispatching to IDBRequest and set/unset it around the actual IDBEventDispatcher::dispatch() call.

This might be a (new?) Worker/V8 bug, though - it seems like allowing GC to kick in at this point is a little sketchy.

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