Bug 77868 – LayoutTest failures on r106797

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Tony Gentilcore]

Several indexeddb related LayoutTests began failing with r106797:
ASSERTION FAILED: iter->first->suspendIfNeededCalled()


storage/indexeddb/createObjectStore-null-name.html
storage/indexeddb/cursor-index-delete.html
storage/indexeddb/cursor-skip-deleted.html
storage/indexeddb/create-object-store-options.html
storage/indexeddb/cursor-primary-key-order.html
storage/indexeddb/cursor-delete.html
storage/indexeddb/deleteIndex.html
storage/indexeddb/deleteObjectStore-null-name.html
storage/indexeddb/factory-basics.html
storage/indexeddb/database-basics.html
storage/indexeddb/cursor-update.html
storage/indexeddb/error-causes-abort-by-default.html

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=storage%2Findexeddb%2FcreateObjectStore-null-name.html%2Cstorage%2Findexeddb%2Fcursor-index-delete.html%2Cstorage%2Findexeddb%2Fcursor-skip-deleted.html%2Cstorage%2Findexeddb%2Fcreate-object-store-options.html%2Cstorage%2Findexeddb%2Fcursor-primary-key-order.html%2Cstorage%2Findexeddb%2Fcursor-delete.html%2Cstorage%2Findexeddb%2FdeleteIndex.html%2Cstorage%2Findexeddb%2FdeleteObjectStore-null-name.html%2Cstorage%2Findexeddb%2Ffactory-basics.html%2Cstorage%2Findexeddb%2Fdatabase-basics.html%2Cstorage%2Findexeddb%2Fcursor-update.html%2Cstorage%2Findexeddb%2Ferror-causes-abort-by-default.html


storage/indexeddb/mozilla/cursors.html
storage/indexeddb/mozilla/autoincrement-indexes.html
storage/indexeddb/mozilla/cursor-mutation.html
storage/indexeddb/mozilla/key-requirements-inline-and-passed.html
storage/indexeddb/mozilla/object-cursors.html
storage/indexeddb/mozilla/create-index-with-integer-keys.html
storage/indexeddb/mozilla/event-source.html
storage/indexeddb/mozilla/key-requirements-put-null-key.html
storage/indexeddb/mozilla/indexes.html
storage/indexeddb/mozilla/create-objectstore-null-name.html
storage/indexeddb/mozilla/clear.html

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=storage%2Findexeddb%2Fmozilla%2Fcursors.html%2Cstorage%2Findexeddb%2Fmozilla%2Fautoincrement-indexes.html%2Cstorage%2Findexeddb%2Fmozilla%2Fcursor-mutation.html%2Cstorage%2Findexeddb%2Fmozilla%2Fkey-requirements-inline-and-passed.html%2Cstorage%2Findexeddb%2Fmozilla%2Fobject-cursors.html%2Cstorage%2Findexeddb%2Fmozilla%2Fcreate-index-with-integer-keys.html%2Cstorage%2Findexeddb%2Fmozilla%2Fevent-source.html%2Cstorage%2Findexeddb%2Fmozilla%2Fkey-requirements-put-null-key.html%2Cstorage%2Findexeddb%2Fmozilla%2Findexes.html%2Cstorage%2Findexeddb%2Fmozilla%2Fcreate-objectstore-null-name.html%2Cstorage%2Findexeddb%2Fmozilla%2Fclear.html


http/tests/inspector/indexeddb/database-structure.html

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=http%2Ftests%2Finspector%2Findexeddb%2Fdatabase-structure.html

[Allan Sandfeld Jensen]

Created attachment 125642 [details]
Patch

Catch one more derived class of ActiveDOMObject.

[Simon Hausmann]

Comment on attachment 125642 [details]
Patch

Seems like the same pattern as in http://trac.webkit.org/changeset/106797 . rs=me

[Tony Gentilcore]

Comment on attachment 125642 [details]
Patch

Clearing flags on attachment: 125642

Committed r106806: <http://trac.webkit.org/changeset/106806>

[Tony Gentilcore]

All reviewed patches have been landed.  Closing bug.

[Tony Gentilcore]

After getting Allan's permission on #webkit, I used webkit-patch land-attachment to green things up without waiting for the cq.

[Julien Chaffraix]

I am seeing the same ASSERT triggering in webaudio. There seem to be another instance of ActiveDOMObject there too. Is it possible that we are missing the same fix there?

[Allan Sandfeld Jensen]

(In reply to comment #6)
> I am seeing the same ASSERT triggering in webaudio. There seem to be another instance of ActiveDOMObject there too. Is it possible that we are missing the same fix there?

It is possible. I have checked all classes directly derived from ActiveDOMObject, and all classes indirectly derived from ActiveDOMObject used by Qt. But I might have missed a classes indirectly inheriting from ActiveDOMObject in modules not used by Qt.

If this is the case, it can be fixed by calling suspendIfNeeded() in the create class.