Closed
Bug 1319737
Opened 9 years ago
Closed 9 years ago
Intermittent errors/crashes when storing wasm modules in indexeddb
Categories
(Core :: Storage: IndexedDB, defect, P2)
Core
Storage: IndexedDB
Tracking
()
RESOLVED
DUPLICATE
of bug 1319531
People
(Reporter: bbouvier, Assigned: asuth)
References
Details
Attachments
(1 file)
3.48 MB,
application/zip
|
Details |
[Tracking Requested - why for this release]: idb issues with wasm caching
STR:
- go to https://benj.me/wasm-idb/
Expected:
- on the first load (creation of IDB and store), sometimes there's an instance of UnknownError during the storeWasm() call, which pretty much creates a new transaction, retrieves the store and calls set(module, 1). It happens in an intermittent fashion and can be reproduced by deleting the store manually in the devtools, then reloading the page.
- reload the page a few times in a row: sometimes the retrieved object from IDB doesn't seem to be a module (it fails in instantiate() by saying that the first argument isn't a wasm module; it is supposed to fail there but only because we don't provide imports during instanciation), sometimes it crashes the entire browser (not only the current tab) and prints this in the (bash) console:
Assertion failure: (mType) == (aType) (unexpected type tag), at /builds/slave/m-cen-l64-ntly-000000000000000/build/src/obj-firefox/ipc/ipdl/_ipdlheaders/mozilla/dom/indexedDB/PBackgroundIDBSharedTypes.h:277
It seems to reproduce more easily when running a local server, so I've attached a zip with the files:
- unzip content
- in the same directory, run: python -m SimpleHTTPServer
- go to http://localhost:8000/test-case.html
![]() |
||
Comment 1•9 years ago
|
||
The first issue might be bug 1319531.
Comment 3•9 years ago
|
||
Hi Janv, any ideas of what's happening here? Does this a blocker of wasm? If so, then I tend to think this is P1.
Flags: needinfo?(jvarga)
Comment 4•9 years ago
|
||
I have no idea why this is happening, but it's definitely a blocker of wasm.
Flags: needinfo?(jvarga)
Comment 5•9 years ago
|
||
Andrew Sutherland said he could take a look here.
Flags: needinfo?(bugmail)
Priority: -- → P2
Assignee | ||
Comment 6•9 years ago
|
||
(Forgot to hit "save changes" when I thought I took this earlier today. Also looking at bug 1319531 which indeed seems to be the cause of the first load error, and which likely could also explain the second error. This may end up getting duped to that.)
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•9 years ago
|
||
Duping to bug 1319531 with fix for that coming shortly.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bugmail)
Resolution: --- → DUPLICATE
Assignee | ||
Comment 8•8 years ago
|
||
Clearing tracking status which was propagated to the duped-to in bug 1319531 comment 10.
You need to log in
before you can comment on or make changes to this bug.
Description
•