1755632 - Site hangs for a long time on PWebGL or BHR?

Status: NEW

(Core :: Graphics: CanvasWebGL, defect)

Description

[Karl Dubost💡 :karlcow]

Firefox freezes when the site loading.

Steps to reproduce.

1. just go to https://www.winamp.com/

Here a performance profile.
https://share.firefox.dev/36gUkxx

[Tracking Requested - why for this release]: Winamp is not a top site but probably known enough that a waiting time of 13s warrant some performance investigation.

Maybe would be good to figure out if it's a regression.

Comment 1

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

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

I see shorter hangs on builds from a few years ago, but it's still pretty slow to load even then. I don't think we're going to get a useful regression range here. Chrome is pretty slow too.

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

(I see the same performance problems in Chrome, so there was no need to track this bugfor 98)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

I get "Something big is happening. We’re building Winamp for the next-generation. Not just updated, but totally remastered." and I can scroll down the page to see some more information about the update. But no hangs. Same behavior also in other browsers.
This is on Linux.

On Windows there is a hang initially. (How can we hang the parent process that way.)
But interestingly also Edge's UI hangs, at least as badly as Nightly's UI.

Comment 5

[Colin S]

I believe I have encountered this bug visiting target.com, using Firefox 111 on macOS 10.14. The problem at target.com much more severe when you are logged into an account; if you are not logged in and visit the home page it only hangs for a couple of seconds, but when logged in it will hang for long enough (minutes) that I end up having to kill the browser.

This bug is severe in that it causes the entire browser to become non-responsive, because the main thread gets stuck waiting for a lock on whatever mutex is causing the problem. Unlike the OP’s case, the Firefox profiler here shows that everything is stuck on PWebGL::Msg_Initialize, and this is triggered by HTMLCanvasElement.getContext, but seems like there is probably a same root cause so I am reporting here instead of making a new ticket.

Unfortunately, I cannot upload the Firefox profile I generated because it contains irrelevant sensitive data, but here is the stack trace from within the Firefox profiler for the affected JS call:

__psynch_cvwait
mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&)
fun_81f8c0
fun_38087a0
PWebGL::Msg_Initialize
fun_3749b50
fun_374b9b0
fun_37482d0
fun_3748180
fun_36467f0
HTMLCanvasElement.getContext
fun_e20490
0x29b8d4104144
0x29b8d4486720
getWebglCanvas
getWebglFp
webglKey
get
18426/k/<
k
k
AsyncFunctionNext
fun_16b6c70
js::RunScript
fun_1815000
fun_171e920
fun_17f6170
fun_16b6c70
fun_50eb50
promise callback
fun_4fddf0
fun_1191040
fun_1199380
fun_5741b0
fun_577670
fun_57b2a0
fun_585810
fun_815520
fun_7d9bb0
fun_11cd950
fun_11e1320
fun_1674930
fun_7d9bb0
fun_16740d0
XRE_InitChildProcess
fun_ea0
start
(root)

I am also attaching a sampling profile from the OS showing the state of all Firefox threads when it is hanging. It looks like there is maybe a 30 second timeout on the waiters since the profile shows the PWebGL::Msg_Initialize call stopping and restarting at exactly 30 seconds, and around every 30 seconds the browser becomes responsive again for one frame.

If it would be helpful to have symbolicated traces, if someone wants to let me know how I can do that without uploading sensitive data to profiler.firefox.com, let me know and I will try to do that. Thanks!

Comment 6

[Colin S]

Attachment: Sample of Firefox 1.txt

OS sampling showing most threads stuck waiting for a mutex