Intermittent errors/crashes when storing wasm modules in indexeddb

RESOLVED DUPLICATE of bug 1319531

Status

()

P2
normal
RESOLVED DUPLICATE of bug 1319531
2 years ago
2 years ago

People

(Reporter: bbouvier, Assigned: asuth)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 8813615 [details]
test-case.zip

[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
The first issue might be bug 1319531.
tracking this wasm-related issue for 52
tracking-firefox52: ? → +
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

2 years ago
I have no idea why this is happening, but it's definitely a blocker of wasm.
Flags: needinfo?(jvarga)
Andrew Sutherland said he could take a look here.
Flags: needinfo?(bugmail)
Priority: -- → P2
(Assignee)

Comment 6

2 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

2 years ago
Duping to bug 1319531 with fix for that coming shortly.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(bugmail)
Resolution: --- → DUPLICATE
Duplicate of bug: 1319531
(Assignee)

Comment 8

2 years ago
Clearing tracking status which was propagated to the duped-to in bug 1319531 comment 10.
status-firefox52: affected → ---
status-firefox53: affected → ---
tracking-firefox52: + → ---
You need to log in before you can comment on or make changes to this bug.