Bug#1094429: firefox: lots of tab crashes on arm64

Discussion:

Add Reply

Sebastian Reichel

2025-01-28 03:50:01 UTC

Package: firefox
Version: 134.0.2-2
Severity: important
X-Debbugs-Cc: Mike Hommey <***@debian.org>, Sebastian Reichel <***@debian.org>

Hi,

I see a lot of tab crashes with Debian's firefox binary on arm64 based
T14s Gen6 Snapdragon. Usually when starting firefox or opening a new tab
I am greeted with the tab crash reporter. After a few tries a page is
actually rendered, so its not 100% broken. But with 80% crashes it is
more or less unusable. The same setup on amd64 runs fine and the crashes
also happen in safe mode / without a profile.

Apparently there is no firefox arm64 version in flathub, but I tried the
librewolf 134.0.2 fork from there and I haven't seen a single crash with
that. This suggests the crashes are somehow specific to the Debian
version.

I used minidump-stackwalk as suggested by the firefox project to get
a stacktrace for a few of the dmp files generated by firefox and it
always seems to be due to SIGILL originating from locked_profiler_start
as in the following output from minidump-stackwalk.

--------------------------------------------------------------------------
Operating system: Linux
6.13.0-00060-gcb8f62213e45 #55 SMP PREEMPT Tue Jan 21 23:24:18 CET 2025
CPU: arm64
12 CPUs
Linux debian - trixie (Debian GNU/Linux trixie/sid)

Crash reason: SIGILL / ILL_ILLOPN
Crash address: 0x0000fffff7c071b0
Process uptime: not available

Linux memory map count: 782

Thread 23 WebExtensions (crashed) - tid: 91889
0 libgcc_s.so.1!aarch64_demangle_return_addr [aarch64-unwind.h : 75]
Found by: inlining
1 libgcc_s.so.1!uw_update_context [unwind-dw2.c : 1287 + 0x18]
x0 = 0x0000000000000000 x1 = 0x000000000000000a
x2 = 0x0000fffff7fe13d0 x3 = 0x0003ffffdff84f44
x4 = 0x0000000000000010 x5 = 0x0080808000800000
x6 = 0x16fefeff2eff1e0b x7 = 0x7f7f7f7f7f7f7f7f
x8 = 0x0101010101010101 x9 = 0x0000fffff7c202a8
x10 = 0x0000000000000000 x11 = 0x0000fffff7c20308
x12 = 0x0000000000000000 x13 = 0x0000000000000000
x14 = 0x0000000000000000 x15 = 0x0000000000000028
x16 = 0x0000ffffe2ae2590 x17 = 0x0043fffff1aa6434
x18 = 0x0000000000000002 x19 = 0x0000ffffe2ae1970
x20 = 0x0000ffffe2ae2590 x21 = 0x0043fffff1aa6434
x22 = 0x0000ffffe2ae2108 x23 = 0x0000aaaaaab29ff8
x24 = 0x0000000000000021 x25 = 0x0000aaaaaab67000
x26 = 0x0000000000000000 x27 = 0x0000ffffe2ae2258
x28 = 0x0000ffffe2ae3140 fp = 0x0000ffffe2ae18a0
lr = 0x0000fffff7c07168 sp = 0x0000ffffe2ae18a0
pc = 0x0000fffff7c071b0
Found by: given as instruction pointer in context
2 libgcc_s.so.1!_Unwind_Backtrace [unwind.inc : 326 + 0x8]
sp = 0x0000ffffe2ae18b0 pc = 0x0000fffff7c07adc
Found by: previous frame's frame pointer
3 firefox!<name omitted> [platform.cpp : 171]
Found by: inlining
4 firefox!mozilla::baseprofiler::locked_profiler_start(mozilla::baseprofiler::PSAutoLock const&, mozilla::PowerOfTwo<unsigned int>, double, unsigned int, char const**, unsigned int, mozilla::Maybe<double> const&) [platform.cpp : 3114 + 0x74]
sp = 0x0000ffffe2ae18e0 pc = 0x0000aaaaaab29fcc
Found by: previous frame's frame pointer

[...] (shortened to the relevant part) [...]
--------------------------------------------------------------------------

Greetings,

Sebastian

-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (250, 'unstable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.13.0-00060-gcb8f62213e45 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages firefox depends on:
ii debianutils 5.21
ii fontconfig 2.15.0-2
ii libasound2t64 1.2.13-1+b1
ii libatk1.0-0t64 2.55.0.1-1
ii libc6 2.40-5
ii libcairo-gobject2 1.18.2-2
ii libcairo2 1.18.2-2
ii libdbus-1-3 1.16.0-1
ii libevent-2.1-7t64 2.1.12-stable-10+b1
ii libffi8 3.4.6-1
ii libfontconfig1 2.15.0-2
ii libfreetype6 2.13.3+dfsg-1
ii libgcc-s1 14.2.0-12
ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-2
ii libglib2.0-0t64 2.82.4-2
ii libgtk-3-0t64 3.24.43-5
ii libnspr4 2:4.36-1
ii libnss3 2:3.107-1
ii libpango-1.0-0 1.56.1-1
ii libstdc++6 14.2.0-12
ii libvpx9 1.15.0-1
ii libx11-6 2:1.8.10-2
ii libx11-xcb1 2:1.8.10-2
ii libxcb-shm0 1.17.0-2+b1
ii libxcb1 1.17.0-2+b1
ii libxcomposite1 1:0.4.6-1
ii libxdamage1 1:1.1.6-1+b2
ii libxext6 2:1.3.4-1+b3
ii libxfixes3 1:6.0.0-2+b4
ii libxrandr2 2:1.5.4-1+b3
ii procps 2:4.0.4-6
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages firefox recommends:
ii libavcodec61 7:7.1-3+b2

Versions of packages firefox suggests:
ii fonts-lmodern 2.005-1
pn fonts-stix | otf-stix <none>
ii libcanberra0 0.30-17+b1
ii libgssapi-krb5-2 1.21.3-3
pn pulseaudio <none>

-- no debconf information

Mike Hommey

2025-01-28 05:20:01 UTC

Permalink

Post by Sebastian Reichel
Package: firefox
Version: 134.0.2-2
Severity: important
Hi,
I see a lot of tab crashes with Debian's firefox binary on arm64 based
T14s Gen6 Snapdragon. Usually when starting firefox or opening a new tab
I am greeted with the tab crash reporter. After a few tries a page is
actually rendered, so its not 100% broken. But with 80% crashes it is
more or less unusable. The same setup on amd64 runs fine and the crashes
also happen in safe mode / without a profile.
Apparently there is no firefox arm64 version in flathub, but I tried the
librewolf 134.0.2 fork from there and I haven't seen a single crash with
that. This suggests the crashes are somehow specific to the Debian
version.
I used minidump-stackwalk as suggested by the firefox project to get
a stacktrace for a few of the dmp files generated by firefox and it
always seems to be due to SIGILL originating from locked_profiler_start
as in the following output from minidump-stackwalk.

The SIGILL is actually happening in libgcc_s.so.1, and the faulting
instructions is autia1716. I'm not sure how much Firefox is at fault
here. The "good" news, at least, is that I can reproduce in a VM on
a mac.

Mike

Mike Hommey

2025-01-28 22:20:01 UTC

Permalink

Post by Mike Hommey

Here is a workaround:
- go to about:config
- in the search field, search for "phc"
- flip "memory.phc.enabled" to false

Mike

Sebastian Reichel

2025-01-28 23:40:01 UTC

Permalink

Hi,

Post by Mike Hommey

- go to about:config
- in the search field, search for "phc"
- flip "memory.phc.enabled" to false

I can confirm, the huge amount of crashes is gone with that option.
Thanks!

-- Sebastian

Sebastian Reichel

2025-01-28 23:20:01 UTC

Permalink

Hi,

Post by Mike Hommey

The SIGILL is actually happening in libgcc_s.so.1, and the faulting
instructions is autia1716. I'm not sure how much Firefox is at fault
here.

I saw that it points to libgcc_s.so.1, but wasn't sure if that is
due to firefox calling into libgcc with bad arguments. Since it
obviously at least affects firefox I opened the bug report here,
but we can reassign of course.

What I can say is that the crashes also happens with libgcc-s1
15-20250114-1 from experimental.

I also had a look at the build flags for flathub's librewolf. It
has been build with clang 18 instead of clang 19. Also quite a few
of the security flags are missing. For C++ (as the code jumping to
libgcc-s is platform.cpp) I mainly see -fstack-protector-strong,
-fstack-clash-protection and -mbranch-protection=standard missing
in the flathub build. It is also using libgcc_s.so.1 from GCC14
(but not Debian's copy). To gain some more data I replaced flathub's
libgcc_s.so.1 copy with Debian's and librewolf keeps working.

Post by Mike Hommey
The "good" news, at least, is that I can reproduce in a VM on a mac.

VM as in "I cannot reproduce when running natively; the VM is needed
to reproduce" or as in "I need the VM because I'm not running
Linux/Debian natively on the MAC"?

Greetings,

-- Sebastian

Mike Hommey

2025-01-28 23:40:01 UTC

Permalink

Post by Sebastian Reichel

Post by Mike Hommey
The "good" news, at least, is that I can reproduce in a VM on a mac.

VM as in "I cannot reproduce when running natively; the VM is needed
to reproduce" or as in "I need the VM because I'm not running
Linux/Debian natively on the MAC"?

The latter.

At this point, I've isolated the problem, reproduced outside Firefox,
and I'm at the point where I need to figure out whether the problem is
in libgcc or glibc to redirect appropriately. All things considered, I'm
quite puzzled that it's not happening with librewolf, or even the
official Mozilla.org arm64 build, but I was able to reproduce the
problem with a local build of an unmodified Firefox using the toolchains
Mozilla uses to build the official build.

Mike

Mike Hommey

2025-01-29 00:10:02 UTC

Permalink

Post by Mike Hommey

Post by Sebastian Reichel

Post by Mike Hommey
The "good" news, at least, is that I can reproduce in a VM on a mac.

VM as in "I cannot reproduce when running natively; the VM is needed
to reproduce" or as in "I need the VM because I'm not running
Linux/Debian natively on the MAC"?

Scrap that. I got it to happen on that build while looking why it wasn't
happening. There's a race condition on the minidump creation, though,
and I'm unable to get the corresponding crash report.

Mike

Mike Hommey

2025-01-29 04:30:02 UTC

Permalink

Post by Mike Hommey

Post by Sebastian Reichel

Post by Mike Hommey
The "good" news, at least, is that I can reproduce in a VM on a mac.

VM as in "I cannot reproduce when running natively; the VM is needed
to reproduce" or as in "I need the VM because I'm not running
Linux/Debian natively on the MAC"?

The latter.
At this point, I've isolated the problem, reproduced outside Firefox,
and I'm at the point where I need to figure out whether the problem is
in libgcc or glibc to redirect appropriately.

I think the problem is on glibc's end. I filed
https://sourceware.org/bugzilla/show_bug.cgi?id=32612
I'll switch PHC off in the meantime.

Mike