4 ms·

Since upgrading to 118 I've had random hangs of firefox every few days. Not clear why, no CPU or swap. All windows just freeze and need a "killall firefox", whi

by ta1243 3y ago

Since upgrading to 118 I've had random hangs of firefox every few days. Not clear why, no CPU or swap. All windows just freeze and need a "killall firefox", which works - shutting firefox down cleanly. Of course it's impossible to find anything anywhere about this due to search engine spam Was fine for years until 118 and is rare enough to not be able to reliably reproduce it (and thus do things like disabling extensions, running the pain of a new profile, etc), so I guess I have to live with it, as life's too short.

krona 3y ago
Same for me. It happened twice yesterday.
qup 3y ago
I've been getting these but I hadn't figured out what to blame yet. I imagined it was one tab doing something bad. I'll have to pay attention now to if it's happening on all my machines. it for sure happened on a Windows 10 machine
flanfly 3y ago
I got these on Brave on two different computers. Disabling hardware acceleration fixed it. Both had Intel graphics.
OfSanguineFire 3y ago
Are you using anything other than a Linux distro’s stable, extended-support release? Most of the complaints on HN about Firefox instability seem to be either Windows users, or Linux users upgrading to the latest and greatest, often outside of their distro’s packaging. Meanwhile, I have been running Debian stable’s Firefox for many years and simply have never encountered the bugginess that gets described on these HN threads.
- dinosaurdynasty 3y ago
  Debian uses Firefox ESR. It's rare for Linux distros to use ESR (Ubuntu and derivatives notably don't, I don't think flatpak does either).
- PaulDavisThe1st 3y ago
  And I on the other hand use Mozilla's latest & greatest all the time on Debian, and "simply have never encountered the bugginess that gets described on these HN threads" either. So there's that ...
- wizzwizz4 3y ago
  I use Debian's Firefox ESR, and for at least five major (ESR) versions there's been a bug where sometimes if multiple tabs try to do a web push notification at once, the entire browser process hangs maxing out a core and nothing I do will recover from that. (I use X11 with PulseAudio.) One of these days, I'll get around to reliably reproducing it. (I haven't tried `pulseaudio -k`, which might fix it if it's an issue playing the sound: videos hang kinda like that, though more recoverably, if the sound isn't working right.)
  - heavyset_go 3y ago
    Have you tried stress testing triggering notifications over D-Bus or something? Might be a DE problem.
    - wizzwizz4 3y ago
      I have not: I don't know how to do that. (I guess you can do it with a Python script?) The X11 utils reckons that the notification windows belong to the same client as Firefox, though, so I doubt this is the issue.
      - heavyset_go 3y ago
        Don't think you'd need to break out Python, you can trigger notifications from the command line or D-Bus itself. https://wiki.archlinux.org/title/Desktop_notifications#Usage_in_programming https://wiki.archlinux.org/title/Desktop_notifications#Usage...
        wizzwizz4 3y ago
        I've confirmed that it's the x-www-browser process maxing out the core, so I doubt it's the DE, and it probably isn't D-Bus either.
  - kiwijamo 3y ago
    Same here, I also use Firefox ESR from Debian packages and I've observed Firefox to lock up hard a few times. Often to the point it affects the entire desktop so not quite sure if it's a bug in Firefox itself or possibly elsewhere e.g., Wayland.
yorwba 3y ago
Does it happen while typing? Might be https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 I'm affected by that bug, but I hadn't considered to search for a ticket until now. Guess I'll have to start using plain Mozilla binaries to reproduce...
padenot 3y ago
Firefox developer here. There are a few ways to diagnose this, depending on your setup. If everything is frozen on Linux, it's probably the parent process that is having an issue. The "parent process" is the process that oversees all the tabs, it's the top process in a Firefox process tree, the one that has lots of children. If our crash reporter is enabled, you can also just kill the parent process with `SIGABRT`, this will produce an entry in `about:crashes` that you can look up on restart, and submit. This will then give a link to our crash reporting front-end. If you have `gdb` and `debuginfod` on your distro, and you're using your distro's Firefox, attach `gdb` to the parent process of Firefox, let it download symbols, and do `thread all apply bt`, this will dump the stacks of all the threads of your parent process. If you're using one of our Firefox builds, you can use https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/Using_the_Mozilla_symbol_server.html#downloading-symbols-on-linux-mac-os-x https://firefox-source-docs.mozilla.org/toolkit/crashreporte..., that will integrate with our own symbol servers. Depending on your distro this might or might not work on your distro's Firefox (some distros submit their symbols to our infra to help diagnosing crashes). Once you have some info about the crash, you can open a ticket on your distro bug tracker, or https://bugzilla.mozilla.org/enter_bug.cgi?product=Core https://bugzilla.mozilla.org/enter_bug.cgi?product=Core to reach us directly, attaching the stacks, Firefox version, crash report, about:support, or anything else that you think is relevant. Oftentimes, those freezes (on Linux) are caused by a bug between Firefox and the desktop environment, or by graphics drivers, that kind of thing, and stacks allow narrowing down the issue greatly, sometimes it's just a package update or a configuration flip away!
- ce4 3y ago
  Wow, thanks for the information! Side question: what can be done on Windows in such a case?
  - padenot 3y ago
    taskkill /F firefox.exe or something like that.
- LoganDark 3y ago
  Holy crap, this is the most helpful answer I've ever seen from a Firefox developer on HN. When I was having a memory exhaustion issue, I was just told "enable the page file, running without overcommit is a recipe for disaster" (looks at my 40GB of memory). I should figure out if that issue still occurs.
pivo 3y ago
Same for me on a mac. I only saw this on 118 and haven't seen them again since upgrading to 119.0 Edit: Spoke too soon. Just happened again while joining a GoogleMeet meeting, if that's relevant.
emgeee 3y ago
throwing in a "same here" -- macosx v118 and 119
lazulicurio 3y ago
Are you on linux? For a while I've been running into issues with FF where it will randomly halt repainting after switching tabs. The process is clearly still responding to keystrokes and mouse events, but the ui is mostly frozen. I've also been running into an annoying issue where hover menus will randomly stop working---it seems like the mouseout event is firing before the click event is handled. But all in all not annoying enough to switch.

by ta1243 3y ago

krona 3y ago

Same for me. It happened twice yesterday.

qup 3y ago

I've been getting these but I hadn't figured out what to blame yet. I imagined it was one tab doing something bad. I'll have to pay attention now to if it's happening on all my machines. it for sure happened on a Windows 10 machine

flanfly 3y ago

I got these on Brave on two different computers. Disabling hardware acceleration fixed it. Both had Intel graphics.

OfSanguineFire 3y ago

Are you using anything other than a Linux distro’s stable, extended-support release? Most of the complaints on HN about Firefox instability seem to be either Windows users, or Linux users upgrading to the latest and greatest, often outside of their distro’s packaging. Meanwhile, I have been running Debian stable’s Firefox for many years and simply have never encountered the bugginess that gets described on these HN threads.

dinosaurdynasty 3y ago
Debian uses Firefox ESR. It's rare for Linux distros to use ESR (Ubuntu and derivatives notably don't, I don't think flatpak does either).
PaulDavisThe1st 3y ago
And I on the other hand use Mozilla's latest & greatest all the time on Debian, and "simply have never encountered the bugginess that gets described on these HN threads" either. So there's that ...
wizzwizz4 3y ago
I use Debian's Firefox ESR, and for at least five major (ESR) versions there's been a bug where sometimes if multiple tabs try to do a web push notification at once, the entire browser process hangs maxing out a core and nothing I do will recover from that. (I use X11 with PulseAudio.) One of these days, I'll get around to reliably reproducing it. (I haven't tried `pulseaudio -k`, which might fix it if it's an issue playing the sound: videos hang kinda like that, though more recoverably, if the sound isn't working right.)
- heavyset_go 3y ago
  Have you tried stress testing triggering notifications over D-Bus or something? Might be a DE problem.
  - wizzwizz4 3y ago
    I have not: I don't know how to do that. (I guess you can do it with a Python script?) The X11 utils reckons that the notification windows belong to the same client as Firefox, though, so I doubt this is the issue.
    - heavyset_go 3y ago
      Don't think you'd need to break out Python, you can trigger notifications from the command line or D-Bus itself. https://wiki.archlinux.org/title/Desktop_notifications#Usage_in_programming https://wiki.archlinux.org/title/Desktop_notifications#Usage...
      - wizzwizz4 3y ago
        I've confirmed that it's the x-www-browser process maxing out the core, so I doubt it's the DE, and it probably isn't D-Bus either.
- kiwijamo 3y ago
  Same here, I also use Firefox ESR from Debian packages and I've observed Firefox to lock up hard a few times. Often to the point it affects the entire desktop so not quite sure if it's a bug in Firefox itself or possibly elsewhere e.g., Wayland.

yorwba 3y ago

Does it happen while typing? Might be https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 I'm affected by that bug, but I hadn't considered to search for a ticket until now. Guess I'll have to start using plain Mozilla binaries to reproduce...

padenot 3y ago

Firefox developer here. There are a few ways to diagnose this, depending on your setup. If everything is frozen on Linux, it's probably the parent process that is having an issue. The "parent process" is the process that oversees all the tabs, it's the top process in a Firefox process tree, the one that has lots of children. If our crash reporter is enabled, you can also just kill the parent process with `SIGABRT`, this will produce an entry in `about:crashes` that you can look up on restart, and submit. This will then give a link to our crash reporting front-end. If you have `gdb` and `debuginfod` on your distro, and you're using your distro's Firefox, attach `gdb` to the parent process of Firefox, let it download symbols, and do `thread all apply bt`, this will dump the stacks of all the threads of your parent process. If you're using one of our Firefox builds, you can use https://firefox-source-docs.mozilla.org/toolkit/crashreporter/crashreporter/Using_the_Mozilla_symbol_server.html#downloading-symbols-on-linux-mac-os-x https://firefox-source-docs.mozilla.org/toolkit/crashreporte..., that will integrate with our own symbol servers. Depending on your distro this might or might not work on your distro's Firefox (some distros submit their symbols to our infra to help diagnosing crashes). Once you have some info about the crash, you can open a ticket on your distro bug tracker, or https://bugzilla.mozilla.org/enter_bug.cgi?product=Core https://bugzilla.mozilla.org/enter_bug.cgi?product=Core to reach us directly, attaching the stacks, Firefox version, crash report, about:support, or anything else that you think is relevant. Oftentimes, those freezes (on Linux) are caused by a bug between Firefox and the desktop environment, or by graphics drivers, that kind of thing, and stacks allow narrowing down the issue greatly, sometimes it's just a package update or a configuration flip away!

ce4 3y ago
Wow, thanks for the information! Side question: what can be done on Windows in such a case?
- padenot 3y ago
  taskkill /F firefox.exe or something like that.
LoganDark 3y ago
Holy crap, this is the most helpful answer I've ever seen from a Firefox developer on HN. When I was having a memory exhaustion issue, I was just told "enable the page file, running without overcommit is a recipe for disaster" (looks at my 40GB of memory). I should figure out if that issue still occurs.

pivo 3y ago

Same for me on a mac. I only saw this on 118 and haven't seen them again since upgrading to 119.0 Edit: Spoke too soon. Just happened again while joining a GoogleMeet meeting, if that's relevant.

emgeee 3y ago

throwing in a "same here" -- macosx v118 and 119

lazulicurio 3y ago

Are you on linux? For a while I've been running into issues with FF where it will randomly halt repainting after switching tabs. The process is clearly still responding to keystrokes and mouse events, but the ui is mostly frozen. I've also been running into an annoying issue where hover menus will randomly stop working---it seems like the mouseout event is firing before the click event is handled. But all in all not annoying enough to switch.