This bug was filed from MDN. Firefox is hanging, and manually crashing produces this crash report: bp-4ee570d5-1e91-41ac-89ad-c6e3e2141207 There are no specific steps to produce it, but if left on its own, Firefox would eventually [@ OOM | small ] crash like bp-0ce9d8a4-3f84-41bc-a9df-bcd8e2141204 Hope this report is useful on solving [@ OOM | small ].
Do you think the hang is related to subsequent OOM crash? The crash reports don't seem related. The hang is at mozilla::widget::WinUtils::WaitForMessage(unsigned long) which basically just means "Firefox is stuck waiting for input". Does the hang resolve itself if you move the mouse around?
At the time I triggered the crash all Firefox windows were mostly white empty spaces with random black artifacts were images should be, the white area covers for both web content and Firefox UI. Clicking or mousing around would just get the OOM small eventually.
I think I've seen this before on my own machine but I was unable to attach to it with a debugger at that point. FWIW I don't think that WaitForMessage is an issue here; if this is similar to what I've seen in the past, this is just an epic graphics fail where we don't paint/composite properly anymore.
Alex, is this gone for you?
¡Hola Wayne! I haven't seen this in a while. Is it still a good idea to fiddle with hangmonitor.timeout to try and catch hangs? If so, what's a good value for it? ¡Gracias!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(alex_mayorga) → needinfo?(vseerror)
Resolution: --- → WORKSFORME
(In reply to alex_mayorga from comment #5) > ... > Is it still a good idea to fiddle with hangmonitor.timeout to try and catch > hangs? If so, what's a good value for it? I don't think that's needed
You need to log in before you can comment on or make changes to this bug.