IDBObjectStore.put throws exception when using in-line key for caching a compiled WebAssembly module
Reported by
alexsuvo...@unity3d.com,
Nov 8 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Steps to reproduce the problem: 1. Enable WebAssembly structured cloning (chrome://flags/#enable-webassembly) 2. Open https://files.unity3d.com/alexsuvorov/bugs/chrome-inline-key-wasm-caching/ 3. Check the console output What is the expected behavior? For testing purposes, the compiled WebAssembly module is stored in two different stores. One store is using in-line "url" key, and another store is using out-of-line "url" key. If both operations complete successfully, the console should display: [WasmCache] Successfully cached wasm module using in-line key [WasmCache] Successfully cached wasm module using out-of-line key What went wrong? When using in-line key in Chrome, store.put({url: url, module: module}) throws the following exception: DataError: Failed to execute 'put' on 'IDBObjectStore': Evaluating the object store's key path did not yield a value. Did this work before? No Chrome version: Version 62.0.3202.89 (Official Build) (64-bit) Channel: n/a OS Version: 10.0 Flash Version: The module caching code can be found on the main page at https://files.unity3d.com/alexsuvorov/bugs/chrome-inline-key-wasm-caching/ The complexity of the cached object does not seem to make any difference, for example, store.put({url: url, module: module}, url) works just fine when using out-of-line keys. The issue can be reproduced on Mac in both 62.0.3202.75 (64-bit) and 64.0.3261.0 canary (64-bit). The issue is not present in Firefox.
,
Nov 8 2017
pwnall@ - can you take a look?
,
Nov 8 2017
,
Nov 9 2017
Suspicion: we serialize on put(), then immediately deserialize to compute the keys (per spec, to avoid side effects). It's possible the deserialization fails due to the module (because we have a bug, presumably) and so we fail to get a key.
,
Nov 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2f6f223cac2ea86d22a3ef815d6b99f971eeed09 commit 2f6f223cac2ea86d22a3ef815d6b99f971eeed09 Author: Victor Costan <pwnall@chromium.org> Date: Tue Nov 14 03:51:23 2017 IndexedDB: Enable WASM decoding in structured cloning done when writing. According to the IndexedDB specification, when writing a value to an object store, keys (primary key and index keys) must be extracted from a structured clone of the value to be written (this avoids exposing implementation details via side-effects). We currently do not turn on WASM module deserialization when doing the structured clone. This went unnoticed until now because we only do the structured clone when we need to compute keys (i.e. when writing to an object store with a primary key or with indexes). This CL fixes the oversight. The WPT test passes with the "WebAssembly structured cloning support" flag enabled. Bug: 782633 Change-Id: I695bd51231d898139165469633c6d63ffdaae262 Reviewed-on: https://chromium-review.googlesource.com/764808 Commit-Queue: Victor Costan <pwnall@chromium.org> Reviewed-by: Jeremy Roman <jbroman@chromium.org> Reviewed-by: Daniel Murphy <dmurph@chromium.org> Cr-Commit-Position: refs/heads/master@{#516182} [add] https://crrev.com/2f6f223cac2ea86d22a3ef815d6b99f971eeed09/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/wasm-module-value-expected.txt [add] https://crrev.com/2f6f223cac2ea86d22a3ef815d6b99f971eeed09/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/wasm-module-value.html [modify] https://crrev.com/2f6f223cac2ea86d22a3ef815d6b99f971eeed09/third_party/WebKit/Source/bindings/modules/v8/V8BindingForModules.cpp [modify] https://crrev.com/2f6f223cac2ea86d22a3ef815d6b99f971eeed09/third_party/WebKit/Source/bindings/modules/v8/V8BindingForModules.h [modify] https://crrev.com/2f6f223cac2ea86d22a3ef815d6b99f971eeed09/third_party/WebKit/Source/modules/indexeddb/IDBValueWrapping.cpp
,
Nov 14 2017
This bug should now be fixed. The fix will appear in the first Canary built past commit position 516182. This should be 64.0.3266.0 or 64.0.3266.0. To check, look for branch_base_position in the Canary lines of https://omahaproxy.appspot.com/ |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by e...@chromium.org
, Nov 8 2017