NS_ERROR_DOM_INVALID_STATE_ERR "invalid state error" in complex worker / Blob / createImageBitmap / GC interaction
Categories
(Core :: DOM: Workers, defect, P3)
Tracking
()
People
(Reporter: guentherhanslphdyt, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0
Steps to reproduce:
Start many web workers in quick succession and transfer fairly large png images (26MB) to each of them.
16 files were uploaded, one for each worker.
The second test is to transfer a lot of small jpg files (40x 300kb) to the workers (1 file per worker -> 40 workers).
Here is a reproduction website and repo:
https://lenni009.github.io/ff-worker-issue/
https://github.com/Lenni009/ff-worker-issue
Related issue: https://github.com/webcompat/web-bugs/issues/133387
Actual results:
When copying large files, the worker may throw the error "An attempt was made to use an object that is not, or is no longer, usable"
When starting up a lot of workers, each just with a small file, some workers may just not start at all, or at least not properly execute their code. They do not throw any errors.
When applying a delay between worker startups so they can copy their data, the workers do not throw errors.
Expected results:
The workers should all start, copy their data, execute their code and report back to the main thread. They should not experience interference by other workers who are trying to copy another file.
This works in Chrome.
|
||
Comment 1•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Workers' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•1 year ago
|
||
Thank you for the reproduction and diligence in reporting and documenting the issue in webcompat!
Based on https://github.com/webcompat/web-bugs/issues/133387#issuecomment-1944364641 it looks like the main interesting thing happening is a call to mozilla::dom::WorkerGlobalScope::CreateImageBitmap which is an inherently async process and where there are a bunch of potential invalid state errors to be thrown in canvas so GC could be reasonable involved. The test case worker creation logic does not retain a strong reference to the worker, only adding an onmessage listener which makes GC possible.
However, a StrongWorkerRef is being obtained by CreateImageBitmap. That should protect the bulk of the operation, it's possible there could be some kind of race when it comes to the worker ref being dropped (calls-to diagram).
Probably the next course of action would be to reproduce under rr and upload to pernosco although MOZ_LOG=WorkerPrivate:5 would probably also be interesting (although likely confusing without anchoring logs for the image stuff and given all the worker threads that could be going on).
Description
•