Why is Firefox crashing so much lately?

[Gary Dale]

I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over X
desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that creates
a PDF or just has a complicated link. It's annoying.

To visit some pages, I have to use Chromium instead.  Earlier today I
had to rename a sessionstore-backups json file because Firefox got
caught in loop where it recognized it had a new tab open but the tab
caused it to crash.

I also have found that at least one site refuses to work with 115.
That's been going on for a while. Again, I have to use Chromium for that
site.

[e***@gmx.us]

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over X
desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that creates a > PDF or just has a complicated link. It's annoying.

I have Firefox 115.13.0esr and it rarely crashes for me, and I have dozens
of tabs open. I use straight XFCE, no Plasma. Could be it doesn't do PDFs
well? I use Zathura to view PDFs. It's rather ... "feature free", so I may
change.

Post by Gary Dale
I also have found that at least one site refuses to work with 115. That's
been going on for a while. Again, I have to use Chromium for that site.

Can you say what that site is?

--
An idea that is not dangerous is unworthy of
being called an idea at all. -- Oscar Wilde

[Andrew M.A. Cater]

Post by e***@gmx.us

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over X
desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that
creates a  > PDF or just has a complicated link. It's annoying.

I upgraded from Debian 10 to Debian 12.5 "Bookworm." The NVidia 390
driver no longer works, so I had software rendering because nouveau
apparently can't do GPU rendering. Rather than crashing, the system
essentially froze. After waiting for a VERY long time, I would give up
and cycle power, with my reboot set up to start an empty session, not
the one I had going at time of the power cycle. I replaced the graphics
card with a Quadro K2200, which works with the nvidia-drivers package
that's still part of the Debian 12.5 distro. With GPU rendering, I no
longer have the problem.

HOW did you upgrade? Did you go via 11?

Did you purge all Nvidia drivers at that point? Nouveau works fairly well
if there's no other trace of Nvidia on the system. Freezing is definitely
a symptom of drivers fighting.

I can't do that with my old Dell Vostro 1700 because the NVidia
graphics chip is soldered to the motherboard, and it needs the 340
driver, which is also no longer available.

If this is the Dell with dual chipsets - one Nvidia to do the heavy
graphics, an Intel chipset for basics - like a bunch of gaming laptops
you'd need to look at the Debian Nvidia pages for primus and so on.

If it *just* has Nvidia - at this point, use Nouveau - stop trying to
use Nvidia drivers on old hardware and that Dell is 2008 vintage?

Software movces on - the very latest Nvidia drivers are "more free" but
also incorporate entire RISC-V chipsets on board the latest cards.

I tried several of the methods discussed in this thread to get the
drivers working, but had no success. Maybe I was just holding my mouth
wrong.

See above.

Post by e***@gmx.us
I have Firefox 115.13.0esr and it rarely crashes for me, and I have dozens
of tabs open.  I use straight XFCE, no Plasma.  Could be it doesn't
do PDFs
well?  I use Zathura to view PDFs.  It's rather ... "feature free",
so I may
change.

Also works for me under GNOME but my usage is light - I don't keep
dozens of tabs open.

All a moot point - we'll probably get 128.* soonest as that's the new
ESR.

All best, as ever,

Andy Cater

Post by e***@gmx.us
Can you say what that site is?
--
        An idea that is not dangerous is unworthy of
        being called an idea at all. -- Oscar Wilde

[Andrew M.A. Cater]

Post by Andrew M.A. Cater
HOW did you upgrade? Did you go via 11?

Fresh install on reformatted boot and root partitions.

OK

Post by Andrew M.A. Cater

I can't do that with my old Dell Vostro 1700 because the NVidia
graphics chip is soldered to the motherboard, and it needs the 340
driver, which is also no longer available.

One chipset.

Post by Andrew M.A. Cater
If it *just* has Nvidia - at this point, use Nouveau - stop trying to
use Nvidia drivers on old hardware and that Dell is 2008 vintage?

I gave up trying to install the NVidia 340 driver on Debian 12.5. If
the rendering is unbearably slow, I'll revert to Debian 10.

Please *don't* do that. Debian 10 is out of security support. Debian 11
will receive a final security update on 31st August as it transitions
to Freexian and LTS. Please use Debian stable wherever feasible.

Post by Andrew M.A. Cater
Software movces on - the very latest Nvidia drivers are "more free" but
also incorporate entire RISC-V chipsets on board the latest cards.

These are the very latest cards for a desktop/workstation.

I can't upgrade a soldered-in chip.

So just use Nouveau already on a ~15 year old laptop.

All the very best, as ever,

Andy Cater
(***@debian.org)

[Felix Miata]

Post by Andrew M.A. Cater
So just use Nouveau already on a ~15 year old laptop.

FTR, technically not a good recommendation. Nouveau has multiple meanings.
Employing each individual meaning generally is suboptimal, as it includes the
"reverse-engineered, experimental" nouveau DDX display driver from the .deb
xserver-xorg-video-nouveau, when the default DIX display driver, modesetting,
which is newer technology (though over a decade old), and neither
reverse-engineered nor experimental, would otherwise be employed.

To use the modesetting DIX display driver, the nouveau kernel module is required.
libdrm-nouveau2 is normally a must as well, as is libgl1-mesa-dri, which provides
nouveau_dri.so.

[Gary Dale]

Post by Andrew M.A. Cater

Post by Andrew M.A. Cater
HOW did you upgrade? Did you go via 11?

Fresh install on reformatted boot and root partitions.

OK

Post by Andrew M.A. Cater

I can't do that with my old Dell Vostro 1700 because the NVidia
graphics chip is soldered to the motherboard, and it needs the 340
driver, which is also no longer available.

One chipset.

Post by Andrew M.A. Cater
If it *just* has Nvidia - at this point, use Nouveau - stop trying to
use Nvidia drivers on old hardware and that Dell is 2008 vintage?

I gave up trying to install the NVidia 340 driver on Debian 12.5. If
the rendering is unbearably slow, I'll revert to Debian 10.

Please *don't* do that. Debian 10 is out of security support. Debian 11
will receive a final security update on 31st August as it transitions
to Freexian and LTS. Please use Debian stable wherever feasible.

Post by Andrew M.A. Cater
Software movces on - the very latest Nvidia drivers are "more free" but
also incorporate entire RISC-V chipsets on board the latest cards.

These are the very latest cards for a desktop/workstation.

I can't upgrade a soldered-in chip.

So just use Nouveau already on a ~15 year old laptop.
All the very best, as ever,
Andy Cater

I've been using Debian 12 (Bookworm) on my notebook for the past year
without issues. It does require the NVidia drivers for the external
display to work - something to do with the on-board AMD graphics chipset
apparently.

[Mike Castle]

At my new job I've been using 115.12.0esr for about three weeks now,
with no crashes. However, also XFCE.

At home, I use Mozilla's debian repo as described at
https://support.mozilla.org/en-US/kb/install-firefox-linux#w_install-firefox-deb-package-for-debian-based-distributions
for a while now, currently 128.0. Also XFCE. You could give that or
a manual install a try to see if it is still a problem outside of ESR.

mrc

[Gary Dale]

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that
creates a PDF or just has a complicated link. It's annoying.
To visit some pages, I have to use Chromium instead.  Earlier today I
had to rename a sessionstore-backups json file because Firefox got
caught in loop where it recognized it had a new tab open but the tab
caused it to crash.
I also have found that at least one site refuses to work with 115.
That's been going on for a while. Again, I have to use Chromium for
that site.

Thanks for the tips guys, but I'm not going to switch to XFCE, I'm using
an old AMD graphics card, it's a desktop machine, and the problem isn't
specific to PDFs - although that seems to be one of the major triggers.

My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie before
that.

I'm beginning to suspect it may be related to my recent introduction of
a Pi-Hole into my network. Could it be a problem for Firefox when it
gets a 0.0.0.0 address returned on a DNS lookup?

[Gary Dale]

Post by Gary Dale

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that
creates a PDF or just has a complicated link. It's annoying.
To visit some pages, I have to use Chromium instead.  Earlier today I
had to rename a sessionstore-backups json file because Firefox got
caught in loop where it recognized it had a new tab open but the tab
caused it to crash.
I also have found that at least one site refuses to work with 115.
That's been going on for a while. Again, I have to use Chromium for
that site.

Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of the
major triggers.
My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.
I'm beginning to suspect it may be related to my recent introduction
of a Pi-Hole into my network. Could it be a problem for Firefox when
it gets a 0.0.0.0 address returned on a DNS lookup?

For those asking for a particular site, here's one that has crashed
Firefox twice on me - but not when I visit the page. When I scroll down
using the mouse wheel, it's crashed three times when I get to around item 9.

[Gary Dale]

Post by Gary Dale

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that
creates a PDF or just has a complicated link. It's annoying.
To visit some pages, I have to use Chromium instead.  Earlier today I
had to rename a sessionstore-backups json file because Firefox got
caught in loop where it recognized it had a new tab open but the tab
caused it to crash.
I also have found that at least one site refuses to work with 115.
That's been going on for a while. Again, I have to use Chromium for
that site.

Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of the
major triggers.
My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.
I'm beginning to suspect it may be related to my recent introduction
of a Pi-Hole into my network. Could it be a problem for Firefox when
it gets a 0.0.0.0 address returned on a DNS lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS chain
and Firefox is still crashing frequently. In fact, it's worse today. Now
it crashes when I'm on Facebook and scrolling down using the mouse wheel.

[The Wanderer]

Post by Gary Dale

Post by Gary Dale
Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of
the major triggers.
My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.
I'm beginning to suspect it may be related to my recent
introduction of a Pi-Hole into my network. Could it be a problem
for Firefox when it gets a 0.0.0.0 address returned on a DNS
lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
chain and Firefox is still crashing frequently. In fact, it's worse
today. Now it crashes when I'm on Facebook and scrolling down using
the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.

If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.

Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.

Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only possibility.

[Gary Dale]

Post by The Wanderer

Post by Gary Dale

Post by Gary Dale
Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of
the major triggers.
My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.
I'm beginning to suspect it may be related to my recent
introduction of a Pi-Hole into my network. Could it be a problem
for Firefox when it gets a 0.0.0.0 address returned on a DNS
lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
chain and Firefox is still crashing frequently. In fact, it's worse
today. Now it crashes when I'm on Facebook and scrolling down using
the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.
If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.
Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.
Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only possibility.

Looking at the submitted and unsubmitted reports, it seems the crashing
started on July 10. It always seems to be "CanvasRenderer" as the
culprit with libxul.so as the guilty module. Firefox was reportedly
installed 32 days ago.

Anyway, the Firefox developers have received dozens of automated crash
reports from me over the past10 days.

I do have a rather old graphics card, but it's an AMD one so the drivers
should be OK. I doubt it's anything else hardware related as I'm not
having problems with other programs.

The only other things of note:
1) my screen does briefly go blank sometimes while doing something
involving windows.
2) Plasma 5 isn't saving my desktop when I reboot.

[Gary Dale]

Post by Gary Dale

Post by The Wanderer

Post by Gary Dale

Post by Gary Dale
Thanks for the tips guys, but I'm not going to switch to XFCE, I'm
using an old AMD graphics card, it's a desktop machine, and the
problem isn't specific to PDFs - although that seems to be one of
the major triggers.
My system has been upgrading from earlier versions of Debian since
Potato. I've been on Trixie since it became the new testing. This
crashing of Firefox is a new issue - had few problems with Trixie
before that.
I'm beginning to suspect it may be related to my recent
introduction of a Pi-Hole into my network. Could it be a problem
for Firefox when it gets a 0.0.0.0 address returned on a DNS
lookup?

Well, I can confirm it's not the Pi-Hole. Took it out of the DNS
chain and Firefox is still crashing frequently. In fact, it's worse
today. Now it crashes when I'm on Facebook and scrolling down using
the mouse wheel.

What kind of crashes are we talking about? I think there may be an
'about:crashes' or similar type of page built in to Firefox, which could
give information about what it's seen happen.
If it's memory-access-related, there might be benefit to trying to e.g.
run under valgrind, intentionally reproduce a crash, and see what that
tool reports. Then again, Firefox is a sufficiently complex app that
that might not be fruitful.
Have you tried running any hardware-error checking tools, e.g. one of
the memtest suites? Crashes that frequent (with software, versions, and
data which other people do not reproduce the problem with) suggest a
possible hardware issue to my mind, although if nothing else is
exhibiting visible issues that makes the hardware a less likely culprit.
Is there any possibility that something in the library/etc. stack which
Firefox sits on top of may be unreliable, or at least be of different
versions from those which the people not observing the problem are
using? One obvious candidate would probably be the graphics stack
(driver, firmware, etc.), but that's not necessarily the only
possibility.

Looking at the submitted and unsubmitted reports, it seems the
crashing started on July 10. It always seems to be "CanvasRenderer" as
the culprit with libxul.so as the guilty module. Firefox was
reportedly installed 32 days ago.
Anyway, the Firefox developers have received dozens of automated crash
reports from me over the past10 days.
I do have a rather old graphics card, but it's an AMD one so the
drivers should be OK. I doubt it's anything else hardware related as
I'm not having problems with other programs.
1) my screen does briefly go blank sometimes while doing something
involving windows.
2) Plasma 5 isn't saving my desktop when I reboot.

It's not X11 either. It's happening when I use Plasma 5 on Wayland.

[Sven Joachim]

Post by Gary Dale
I'm running Debian/Trixie on an AMD64 system, using the Plasma 5 over
X desktop. Firefox 115.12.0esr is crashing multiple times per day. It
frequently happens when page I'm transfers to another page that
creates a PDF or just has a complicated link. It's annoying.

Apparently this is bug #1072557[1] in mesa.

Post by Gary Dale
To visit some pages, I have to use Chromium instead.  Earlier today I
had to rename a sessionstore-backups json file because Firefox got
caught in loop where it recognized it had a new tab open but the tab
caused it to crash.

I experienced a similar problem on my laptop where firefox-esr crashed
shortly after the start before even reloading the current tab in all
open windows. The workaround was to run it with LIBGL_ALWAYS_SOFTWARE=1
set in the environment.

Cheers,
Sven


1. https://bugs.debian.org/1072557