Closed Bug 1411520 Opened 7 years ago Closed 7 years ago

new File instance creation from another File instance with new name will crash worker that should work with new file

Categories

(Core :: XPConnect, defect)

58 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: spirindb, Assigned: baku)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.102 Safari/537.36 Vivaldi/1.93.955.38

Steps to reproduce:

1) Read file as an arrayBuffer and save it to the variable (EcmaScript 6+ using babel)
2) Upload it to the server (own development project)
3) Upload it again, get error "Same name conflict":
3.1) Create worker (via webworker-loader using webpack, but it is actually same as "new Worker(path_to_worker_file)")
3.2) Provide worker and set onmessage function doSomeOnMessage(event) {...}
3.3) Try to create "inode"/metainfo-object object on server and get error "Same name conflict"
4) Create new File instance from the existing source with new name
5) Try 3) again and get no conflicts, so provide File into freshly created Worker
6) Split File into blocks and send first block
7) Succefully complete this operation and postMessage back to the main "thread"
8) Tab crash on doSomeOnMessage()


BUT:
1) If you'll immideately terminate worker in doSomeOnMessage() there will be no tab crashes but it prevents from working with workers at all...
2) If there will be no new File instance creation - no tab crashes


Actual results:

Tab crash in
https://github.com/mozilla/gecko-dev/blob/master/dom/workers/WorkerPrivate.cpp

Line:
MOZ_CRASH(All runnables destined for a worker thread must be cancelable!);

Crash-stats:
https://crash-stats.mozilla.com/report/index/2b2e2097-dd08-41f1-8379-93f520171024


Expected results:

No tab crashes
Andrea, do you know what stream loader this is?  It probably needs to use the WorkerPrivate "hybrid" event target to auto-wrap runnables as cancelable.
Flags: needinfo?(amarchesini)
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Attached patch multiplex.patchSplinter Review
We don't need Cancel() here because we don't need to complete ::AsyncWait() if the worker is going away.
Attachment #8921988 - Flags: review?(bkelly)
Attachment #8921988 - Flags: review?(bkelly) → review+
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/05eeb1a900b2
nsMultiplexInputStream must use CancelableRunnable because it can be used in workers, r=bkelly
https://hg.mozilla.org/mozilla-central/rev/05eeb1a900b2
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: