Bug 170000 – A null compound index value crashes the Databases process

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

[Casey]

Posting this here at the recommendation of @beidson here: https://github.com/dfahlander/Dexie.js/issues/494

----

If you specify a compound index, and then subsequently attempt to store a record in IDB and the value for that index is null, Safari >= 10.1 blows up with the error message:

"UnknownError – "An unknown error occurred within Indexed Database."

After this point the database is unusable. It still reports it self as open, but any subsequent calls (e.g., adding an item, opening a transaction) result in further errors.

This affects the iOS 10.3 beta as well.

On Chrome and Firefox, and Safari < 10.1 there is no error, and it works as expected.

--

Sorry for not submitting a pure IDB test case, but I'm only familiar with the Dexie API. Hopefully this can help.

== Test Case ==

source: https://github.com/Ramblurr/dexie-null-compound-index/blob/master/test-case.html
run directly: https://rawgit.com/Ramblurr/dexie-null-compound-index/master/test-case.html

[Casey]

I just found another possibly related bug that is exposed with this test case.

The first time you load the test case it will fail in the affected browsers, then if you reload it, the test hangs. If you open a new tab with the test case, the test case will run.

AFAICT, it seems that once this bug is triggered, after a refresh in the same tab, any calls to IDB (opening a DB, deleting a db) hangs completely.

[Casey]

Created attachment 305198 [details]
com.apple.WebKit.Databases crash log

Here is a crash log!

[Brady Eidson]

Confirmed, I get the same Databases crash when running your test case.

Won't be able to get to this ASAP, but will soon; please leave it at that URL to test when the time comes.

[Radar WebKit Bug Importer]

<rdar://problem/31222351>

[Brady Eidson]

Being asked to serialize an Invalid key, which should never happen.

1   0x12240e2fd WTFCrash
2   0x117151148 WebCore::serializedTypeForKeyType(WebCore::IndexedDB::KeyType)
3   0x11714ffa2 WebCore::encodeKey(WTF::Vector<char, 0ul, WTF::CrashOnOverflow, 16ul>&, WebCore::IDBKeyData const&)
4   0x11715025e WebCore::encodeKey(WTF::Vector<char, 0ul, WTF::CrashOnOverflow, 16ul>&, WebCore::IDBKeyData const&)
5   0x11714ff40 WebCore::serializeIDBKeyData(WebCore::IDBKeyData const&)
….

    case IndexedDB::KeyType::Invalid:
        RELEASE_ASSERT_NOT_REACHED();    <----

[Brady Eidson]

Specifically, the key is an Array that contains an Invalid key.

[Brady Eidson]

The index is not multi-entry, so we collect all the index keys into an array of keys.

We never check to verify that each key in that array is valid.

I'll clarify with the spec what the right behavior is here, but I suspect it's "can't index this put", which might mean the put should fail.

If I get stuck making sense of the spec, I'll dump all the of raw IDB commands that get to this point and try to recreate a pure IDB test case, which might make it more clear.

(Note, I don't have time to take this exploration further right now, but if anybody else wants to do any of the above exploration it can get us closer to resolving this)

[Brady Eidson]

Created attachment 305292 [details]
Fairly reduced test case

[Brady Eidson]

And the right thing to do when any of the keys are invalid is obviously to not put anything in the index.

[Brady Eidson]

Created attachment 305316 [details]
Patch

[Brady Eidson]

Comment on attachment 305316 [details]
Patch

Whoops, left out the private browsing variant

[Brady Eidson]

Created attachment 305318 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 305318 [details]
Patch

Clearing flags on attachment: 305318

Committed r214375: <http://trac.webkit.org/changeset/214375>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.