1965872 - dedicated workers with deeply nested `eval()` freezes the Tab without any CPU use and does othe weird stuff.

Status: NEW

(Core :: DOM: Workers, defect, P3)

Description

[Mayank Bansal]

Attachment: 1000 SW.HTML

Serve the testcase on a HTTP server (maybe BMO will also work if not for its CSP)
Enter 1000
Click on run
Wait till the CPU use subsides

AR: Page is completely unresponsive
ER: Not so

Bisection:
Bug 1899503 - P4 Update SharedWorker windowID for remote worker debugger. r=asuth
Depends on D230260
Differential Revision: https://phabricator.services.mozilla.com/D231778

Comment 1

[Mayank Bansal]

IT also:

1. blocks running about:memory measurement
2. makes many gui operations slow (example: starting the profiler and capturing a profile)
3. You cant press the reload button to refresh the page.
4. remembers the freeze if you navigate and come back:

• repro the testcase, navigate to example.com on the same tab, then press the back arrow.
• The page freezes.

Comment 2

[Mayank Bansal]

not sure if this is a security bug.

Comment 3

[Mayank Bansal]

not sure if this is a security bug.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

I think this would just be an eviltraps bug, not a security bug, but I don't have the bits to clear "Core" sec-bugs. In general, test cases that render a tab completely unresponsive from massive use of resources wouldn't be a security bug unless we see a crash on a poison memory value or some other non-null memory value which would indicate a UAF.

I should note the test case is a bit misleading; it says service worker in a number of places but it's creating 1000 dedicated workers. I think we wouldn't expect the tab to be janked in the SW case, although it possibly could be janked in a SharedWorker case since we could choose the same process.

In terms of the bisection, while I think the specific commit in the stack is suspect, I think the bisection is right about the stack in terms of the changes to how worker debuggers potentially works potentially has a bunch of overhead right now in a way that can block the thread more than it did before.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1899503

:edenchuang, since you are the author of the regressor, bug 1899503, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Mayank Bansal]

Thanks for the analysis, asuth.
To clarify: The freeze occurs without using any CPU.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Mayank Bansal from comment #6)

To clarify: The freeze occurs without using any CPU.

Right, we expect to be parked here waiting on a condvar to be notified in WorkerPrivate::EnableRemoteDebugger each time a new worker is created which will cause problems with things like about:memory and the profiler that are trying to communicate via PContent.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

I'm clearing the regression because the temporary performance hit to worker debugger registering was expected and creating 1,000 workers synchronously without yielding the event loop is not normal use.