1878101 - All Firefox Windows Freeze due to webcam stream from one website

Status: UNCONFIRMED

(Core :: JavaScript: GC, defect, P3)

Description

[markleaf131313]

Attachment: Screenshot 2024-02-01 140041.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

Opening webcam stream in firefox along with another youtube/twitch stream. On a laptop with Ryzen 4700u CPU/iGPU, 16gb RAM.

Actual results:

The webcam stream seems to cause firefox to just hang for a couple of seconds every minute or so. Usually with other windows open as well. Don't think I'm hitting any sort of hardware limit as I can open the stream in Chrome and everything functions fine.

I ran a profiler and it seems to get stuck on a "ZwWaitForSingleObject" function call in display Paint.

Expected results:

Firefox should still be usable and not freeze.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Ray Kraesig [:rkraesig]]

"WrDisplayList" is a WebRender identifier. Refiling appropriately.

Uploading that profiler run would be very helpful, though. If you're concerned about information leakage, there are options to redact various classes of data in the upload menu (including URLs and screenshots), and you can review the redacted profiler run before either linking it here or deleting it. Alternatively or additionally, you can start Firefox under a fresh Firefox user-profile and try to reproduce the issue there.

Comment 3

[markleaf131313]

I've uploaded it using the upload feature in the profiler.

share.firefox.dev/49gebb7

Comment 4

[Lee Salzman [:lsalzman]]

Can you please take another profile using the 'Graphics' preset in the profiler? It's missing some threads in that profile that would help us see what's going on better.

Comment 5

[Lee Salzman [:lsalzman]]

This seems superficially related to bug 1877726. What I see in the renderer thread is a wait in NtGdiDdDDIAcquireKeyedMutex2, which seems super suspicious, but missing some threads that might potentially tell us why it is waiting here.

Comment 6

[markleaf131313]

Okay, I created another profile with the Graphics setting. During upload there's also an option for included hidden threads which I added to include them.

https://share.firefox.dev/49anN7C

Comment 7

[Timothy Nikkel (:tnikkel)]

Are you able to share the webcam site?

Comment 8

[markleaf131313]

It's a locally run server running RatOS, which is a fork of Mainsail.

https://github.com/mainsail-crew/crowsnest

That's the plugin that adds the webcam, it doesn't look like a lot is there though. I'm not sure what you would be looking for if I can gather that information for you? It uses ustreamer to stream in the backend.

https://github.com/Rat-OS/RatOS

I believe moonraker is the name of the subsystem that is the webserver.

Comment 9

[Sotaro Ikeda [:sotaro]]

(In reply to markleaf131313 from comment #6)

Okay, I created another profile with the Graphics setting. During upload there's also an option for included hidden threads which I added to include them.

https://share.firefox.dev/49anN7C

From the profile, mKeyedMutex->AcquireSync(0, 10000) in RenderDXGITextureHost::LockInternal() tool very long time. It seemed that keyed mutex was held by producer of ID3D11Texture2D.

And in Canvas worker thread, destructing ID2D1Image in SourceSurfaceD2D1::~SourceSurfaceD2D1() took very long time. I wonder if it might related to the problem.

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to markleaf131313 from comment #0)

Created attachment 9377762 [details]
Screenshot 2024-02-01 140041.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:122.0) Gecko/20100101 Firefox/122.0

Steps to reproduce:

Opening webcam stream in firefox along with another youtube/twitch stream. On a laptop with Ryzen 4700u CPU/iGPU, 16gb RAM.

markleaf131313, how did you show the webcam stream in firefox?

Comment 11

[markleaf131313]

I'm not sure exactly what you mean, I just put in the IP address of the device running the server, and click on the webcam tab from the website.

Comment 12

[Sotaro Ikeda [:sotaro]]

Ok, thank you. The profiler had Canvas2d task handling. Then I just wondered that video might be rendered to canvas 2d.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Can you try again with today's Firefox Nightly?

Comment 14

[markleaf131313]

It seems to be fixed, but it didn't happen 100% of the time before either. I tried stressing it a bit more by opening more streams than I usually have and it didn't freeze.

Do you know how long it will take for the changes to make it into stable? If it is a long time I can switch over to the nightly version to more accurately test my usage. I tried to have the same windows I usually have open and everything as best I could, if that is good enough or not.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

The fix is supposed to go to stable next week.

Comment 16

[markleaf131313]

I've been testing the new build for a while now and the overall problem of all the windows freezing has been fixed.

The webcam tab (ratos) does still freeze, though none of the other tabs freeze with it.

https://share.firefox.dev/3v4JnvG

It can be seen in the profile upload here, PID 35960 is the ratos tab, which you can see still has a bit of jank to it.

Comment 17

[Glenn Watson [:gw]]

Looks like the remaining jank in that content tab might be JS / GC related rather than gfx?

Comment 18

[Jon Coppeard (:jonco)]

The biggest jank is the 2.6 second cycle collection.

On the GC side, there's an long incremental GC which adds up to 3.2 seconds over 150 slices. One problem here is that the early slices are mostly interrupted and don't run for very long, which prolongs the GC as a whole. We extend the slice budget based on how long the GC has been running and that is why we're getting 100ms slices here.