1866025 - Firefox 120.0 segfaults at startup (Linux with 16KiB pages)

Status: RESOLVED FIXED

(Core :: Memory Allocator, defect, P1)

Description

[Eric Engestrom]

Attachment: firefox.strace

Steps to reproduce:

Running on ArchLinux ARM (in case it's a packaging issue) on Sway 1.8.1 + wlroots 0.16.2 (in case it's a Wayland issue), I got the upgrade from firefox-119.0.1-1-aarch64 to firefox-120.0-1-aarch64; upon restarting Firefox, I got met with a segfault (see strace attached) right at startup, before any window opens. Downgrading back to 119.0.1 fixes the issue (but I have now lost access to my normal profile since Firefox has a new check preventing downgrades; I understand why that check was added, but it's still annoying...)

On the environment side, I have MOZ_DBUS_REMOTE=1 & MOZ_ENABLE_WAYLAND=1 (not sure if it's relevant, I'll try changing these once I've posted this issue since I can't run both versions in parallel. I don't need the dbus one anymore, it was for back when I was still running X sometimes, and I'll try removing the wayland one in case running through xwayland fixes the issue, as that would narrow down the problem.

Actual results:

Segfault (see strace attached)

Expected results:

Firefox starts :)

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Eric Engestrom]

So, this is not a wayland issue: same behaviour without MOZ_ENABLE_WAYLAND or when setting it to 0, and I verified that it does run through xwayland in both cases.

I have also dropped the dbus var, not change either.

Comment 3

[Eric Engestrom]

Also, this is not related to my profile, as running firefox -P gives the same crash

Comment 4

[Martin Stránský [:stransky] (ni? me)]

You can use --allow-downgrade command line argument to use old profile (and backup the original one before you try so).

Comment 5

[Martin Stránský [:stransky] (ni? me)]

Can you try plain Mozilla binaries?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

Please run firefox under gdb and attach the backtrace here:
https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Running_application_in_debugger
(you may need to install debuginfo packages for it).

Comment 7

[Robert Mader [:rmader]]

Just for the record: the arm64 build on Fedora works just fine for me on a PBP and a RPI4 - so potentially something about the arch build. Jan, have you heard about something similar? Not sure if you're the right person to ping about ALARM.

Comment 8

[Jan Alexander Steffens [:heftig]]

Sorry, I'm not involved with Arch Linux ARM.

Comment 9

[Eric Engestrom]

The "Linux 64-bit" option on https://www.mozilla.org/en-US/firefox/all/ redirects me to https://download-installer.cdn.mozilla.net/pub/firefox/releases/120.0/linux-x86_64/en-US/firefox-120.0.tar.bz2, and looking at https://download-installer.cdn.mozilla.net/pub/firefox/releases/120.0/ it seems x86 is the only architecture provided for linux (windows does have an aarch64 build), so I can't test that :(

I'm rebuilding firefox from source (https://archive.mozilla.org/pub/firefox/releases/120.0/source/firefox-120.0.source.tar.xz) now, we'll see how that goes.

firefox -g -d gdb crashes before it starts the debugger, but gdb /usr/lib/firefox/firefox works; the thread apply all bt full output is:

Thread 14 (Thread 0xffffe2a5f0c0 (LWP 51436) "HTML5 Parser"):
#0  0x0000fffff7b0d2d8 in  () at /usr/lib/libc.so.6
#1  0x0000fffff7b0fe84 in pthread_cond_wait () at /usr/lib/libc.so.6
#2  0x0000aaaaaab27abc in mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&) ()
#3  0x0000ffffec7631e4 in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffec76d950 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffecdbc0d8 in  () at /usr/lib/firefox/libxul.so
#7  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#8  0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#9  0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#10 0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#11 0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 13 (Thread 0xffffe2aaf0c0 (LWP 51435) "Backgro~Pool #1"):
#0  0x0000fffff7b0d2d8 in  () at /usr/lib/libc.so.6
#1  0x0000fffff7b10184 in pthread_cond_timedwait () at /usr/lib/libc.so.6
#2  0x0000aaaaaab27c50 in mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) ()
#3  0x0000ffffec772ce0 in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffec76da68 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffecdbc054 in  () at /usr/lib/firefox/libxul.so
#7  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#8  0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#9  0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#10 0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#11 0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 12 (Thread 0xffffe2aff0c0 (LWP 51434) "IPDL Background"):
#0  0x0000fffff7b0d2d8 in  () at /usr/lib/libc.so.6
#1  0x0000fffff7b0fe84 in pthread_cond_wait () at /usr/lib/libc.so.6
#2  0x0000aaaaaab27abc in mozilla::detail::ConditionVariableImpl::wait(mozilla::detail::MutexImpl&) ()
#3  0x0000ffffec7631e4 in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffec76d950 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffecdbc0d8 in  () at /usr/lib/firefox/libxul.so
#7  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#8  0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#9  0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#10 0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#11 0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 11 (Thread 0xffffe2c770c0 (LWP 51433) "Socket Thread"):
#0  0x0000fffff7b704d8 in poll () at /usr/lib/libc.so.6
#1  0x0000fffff6fb7f14 in  () at /usr/lib/libnspr4.so
#2  0x0000ffffec8a7cbc in  () at /usr/lib/firefox/libxul.so
#3  0x0000ffffec8aa4c0 in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffec8a98f0 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffec8aa62c in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffec76da68 in  () at /usr/lib/firefox/libxul.so
#7  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#8  0x0000ffffecdbc054 in  () at /usr/lib/firefox/libxul.so
#9  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#10 0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#11 0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#12 0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#13 0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 10 (Thread 0xffffe2cc70c0 (LWP 51432) "Netlink Monitor"):
#0  0x0000fffff7b704d8 in poll () at /usr/lib/libc.so.6
#1  0x0000ffffecc7a7d0 in  () at /usr/lib/firefox/libxul.so
#2  0x0000ffffec76da68 in  () at /usr/lib/firefox/libxul.so
#3  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffecdbc054 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#7  0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#8  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#9  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 9 (Thread 0xffffe744f0c0 (LWP 51431) "Timer"):
#0  0x0000fffff7b0d2d8 in  () at /usr/lib/libc.so.6
#1  0x0000fffff7b10184 in pthread_cond_timedwait () at /usr/lib/libc.so.6
#2  0x0000aaaaaab27c50 in mozilla::detail::ConditionVariableImpl::wait_for(mozilla::detail::MutexImpl&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator> const&) ()
#3  0x0000ffffec766f04 in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffec76da68 in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffec77161c in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffecdbc054 in  () at /usr/lib/firefox/libxul.so
#7  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#8  0x0000ffffec76b578 in  () at /usr/lib/firefox/libxul.so
#9  0x0000fffff6fbdfd4 in  () at /usr/lib/libnspr4.so
#10 0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#11 0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 8 (Thread 0xffffe749f0c0 (LWP 51430) "IPC I/O Parent"):
#0  0x0000fffff7b76428 in syscall () at /usr/lib/libc.so.6
#1  0x0000ffffecd894f8 in  () at /usr/lib/firefox/libxul.so
#2  0x0000ffffecd8b9b8 in  () at /usr/lib/firefox/libxul.so
#3  0x0000ffffecd734fc in  () at /usr/lib/firefox/libxul.so
#4  0x0000ffffecd718fc in  () at /usr/lib/firefox/libxul.so
#5  0x0000ffffecd79994 in  () at /usr/lib/firefox/libxul.so
#6  0x0000ffffecd772c4 in  () at /usr/lib/firefox/libxul.so
#7  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#8  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 7 (Thread 0xffffe7eef0c0 (LWP 51415) "gdbus"):
#0  0x0000fffff7b704d8 in poll () at /usr/lib/libc.so.6
#1  0x0000fffff6099680 in  () at /usr/lib/libglib-2.0.so.0
#2  0x0000fffff609a2b4 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#3  0x0000fffff5e9db84 in  () at /usr/lib/libgio-2.0.so.0
#4  0x0000fffff60cde4c in  () at /usr/lib/libglib-2.0.so.0
#5  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#6  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 6 (Thread 0xffffe86ff0c0 (LWP 51414) "dconf worker"):
#0  0x0000fffff7b704d8 in poll () at /usr/lib/libc.so.6
#1  0x0000fffff6099680 in  () at /usr/lib/libglib-2.0.so.0
#2  0x0000fffff6099fb4 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x0000ffffe884c7f4 in  () at /usr/lib/gio/modules/libdconfsettings.so
#4  0x0000fffff60cde4c in  () at /usr/lib/libglib-2.0.so.0
#5  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#6  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 5 (Thread 0xffffe90830c0 (LWP 51413) "pool-firefox"):
#0  0x0000fffff7b76424 in syscall () at /usr/lib/libc.so.6
#1  0x0000fffff61049c4 in g_cond_wait_until () at /usr/lib/libglib-2.0.so.0
#2  0x0000fffff6059f54 in  () at /usr/lib/libglib-2.0.so.0
#3  0x0000fffff605a7dc in g_async_queue_timeout_pop () at /usr/lib/libglib-2.0.so.0
#4  0x0000fffff60cebb4 in  () at /usr/lib/libglib-2.0.so.0
#5  0x0000fffff60cde4c in  () at /usr/lib/libglib-2.0.so.0
#6  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#7  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 4 (Thread 0xffffe98930c0 (LWP 51412) "gmain"):
#0  0x0000fffff7b704d8 in poll () at /usr/lib/libc.so.6
#1  0x0000fffff6099680 in  () at /usr/lib/libglib-2.0.so.0
#2  0x0000fffff6099fb4 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#3  0x0000fffff609a03c in  () at /usr/lib/libglib-2.0.so.0
#4  0x0000fffff60cde4c in  () at /usr/lib/libglib-2.0.so.0
#5  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#6  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 3 (Thread 0xfffff77ff0c0 (LWP 51411) "pool-spawner"):
#0  0x0000fffff7b76424 in syscall () at /usr/lib/libc.so.6
#1  0x0000fffff61047a4 in g_cond_wait () at /usr/lib/libglib-2.0.so.0
#2  0x0000fffff6059f98 in  () at /usr/lib/libglib-2.0.so.0
#3  0x0000fffff60ce81c in  () at /usr/lib/libglib-2.0.so.0
#4  0x0000fffff60cde4c in  () at /usr/lib/libglib-2.0.so.0
#5  0x0000fffff7b10aec in  () at /usr/lib/libc.so.6
#6  0x0000fffff7b7a5dc in  () at /usr/lib/libc.so.6

Thread 1 (Thread 0xfffff7f8c8a0 (LWP 51405) "firefox"):
#0  0x0000aaaaaaadcd44 in SetPHCState ()
#1  0x0000ffffec6dfbec in  () at /usr/lib/firefox/libxul.so
#2  0x0000ffffec79072c in  () at /usr/lib/firefox/libxul.so
#3  0x0000fffff02579b4 in  () at /usr/lib/firefox/libxul.so
#4  0x0000fffff02543a0 in  () at /usr/lib/firefox/libxul.so
#5  0x0000fffff0252d9c in  () at /usr/lib/firefox/libxul.so
#6  0x0000fffff0257144 in  () at /usr/lib/firefox/libxul.so
#7  0x0000fffff0257584 in  () at /usr/lib/firefox/libxul.so
#8  0x0000aaaaaaad5c14 in  ()
#9  0x0000fffff7ab7b80 in  () at /usr/lib/libc.so.6
#10 0x0000fffff7ab7c60 in __libc_start_main () at /usr/lib/libc.so.6
#11 0x0000aaaaaaad56b0 in _start ()

Without symbols, I don't know how useful this is; we'll see what it looks like once I've finished compiling it myself.

print DumpJSStack() failed with No symbol "DumpJSStack" in current context. which is not surprising given how early the crash happens

Comment 10

[Sjon Hortensius]

I noticed a refence to Probabilistic Heap Checker in one of my backtraces - is it possible to disable that component? I tried stracing as well and that pointed towards DRI so it might be one of these. My segfault happens on ALARM as well - on a Macbook air m2

Comment 11

[Janne Grunau]

It segfaults on my system (Apple M1 Ultra, 16k page size) with a NULL ptr dereference in SetPHCState. It is expected that gMut is NULL since phc_init() returns early on a page size mismatch between build and runtime: https://searchfox.org/mozilla-central/source/memory/build/PHC.cpp#1076

Either SetPHCState() misses a NULL check or it must not be called when phc_init() returns false.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Sorry didn't mean to close

Comment 13

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: makes Firefox unusable in some systems.

Seems like that'd come from bug 1814798. But that landed in 119, Paul is there something off there or was that somehow reverted on 119?

Comment 14

[Janne Grunau]

(In reply to Janne Grunau from comment #11)

It is expected that gMut is NULL since phc_init() returns early on a page size mismatch between build and runtime: https://searchfox.org/mozilla-central/source/memory/build/PHC.cpp#1076

kPageSize is defined to 4096 (except for macOS/arm64) so it will always fail on a 16k page size linux system.

Does PHC depend on jemalloc? That seem the most likely explanation why the fedora build is not affected.

Comment 15

[Janne Grunau]

Attachment: PHC_SetPHCState_NULL_deref_fix.patch

The obvious NULL check in SetPHCState as attached fixes the and Firefox starts and is usable.
It looks to me like https://bugzilla.mozilla.org/show_bug.cgi?id=1854550 enabled PHC and thus triggered the issue.

Comment 16

[Paul Bone [:pbone]]

(In reply to Janne Grunau from comment #14)

(In reply to Janne Grunau from comment #11)

It is expected that gMut is NULL since phc_init() returns early on a page size mismatch between build and runtime: https://searchfox.org/mozilla-central/source/memory/build/PHC.cpp#1076

kPageSize is defined to 4096 (except for macOS/arm64) so it will always fail on a 16k page size linux system.

Does PHC depend on jemalloc? That seem the most likely explanation why the fedora build is not affected.

Yes it does.

Comment 17

[Paul Bone [:pbone]]

Thanks for the bug report Eric, I'm really sorry that this happened to you and you can't open your profile right now.

Thanks Janne for the patch. That will definitely work, however I'm going to land a slightly different patch that will optionally initialise PHC at this point if it hasn't been already, it'll use the same check as we do in other entrypoints to PHC: https://searchfox.org/mozilla-central/source/memory/build/PHC.cpp#1119-1121

To workaround the issue you could do any one of these:

• Apply the patch and build a new version ;-), either Janne's or mine.
• Use Firefox 119 (but like Eric said, maybe you can't open your profile)
• Build firefox without PHC enabled ac_add_options --disable-phc
• if you can ask Linux to use a 4KiB page size, I don't know how easy/possible this is, or if other software will break.

Comment 18

[Paul Bone [:pbone]]

Attachment: Bug 1866025 - Check if PHC is initialised on all entrypoints r=glandium

PHC initialisation can bail out on systems without an expected statically
assumed page size. When this happens Firefox can crash if we don't check
for it on all PHC entrypoints including SetPHCStatus().

Thanks Janne Grunau for the initial patch.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/42c80086da44
Check if PHC is initialised on all entrypoints r=glandium

Comment 20

[Hector Martin]

if you can ask Linux to use a 4KiB page size, I don't know how easy/possible this is, or if other software will break.

Just for reference, we don't support booting 4K on bare metal as the various IOMMUs in the system only support 16K pages, and Linux can't handle that mismatch (reasonably) right now. We do support 4K VMs (and that's the plan for dealing with legacy software / x86 emulation), but running Firefox in a VM to work around this bug seems a little bit too intrusive :-)

Thank you for the quick fix!

Comment 21

[Emilio Cobos Álvarez (:emilio)]

We should probably uplift it to release asap (or maybe uplift a more minimal version of the patch like comment 15). Wdyt Paul?

Comment 22

[Robert Mader [:rmader]]

IMHO this issue makes a great case that we need Linux aarch64 nightly/beta builds. If possible directly on https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly - maybe instead of x86-32, which probably won't be missed by many :)

Comment 23

[Paul Bone [:pbone]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)

We should probably uplift it to release asap (or maybe uplift a more minimal version of the patch like comment 15). Wdyt Paul?

Yep, that's the plan (I'll uplift my patch). I've been talking with Release folks about it already, and I now have Asahi linux on my Mac Mini so I'll verify it myself then request the uplift.

Comment 24

[Paul Bone [:pbone]]

(In reply to Hector Martin from comment #20)

if you can ask Linux to use a 4KiB page size, I don't know how easy/possible this is, or if other software will break.

Just for reference, we don't support booting 4K on bare metal as the various IOMMUs in the system only support 16K pages, and Linux can't handle that mismatch (reasonably) right now. We do support 4K VMs (and that's the plan for dealing with legacy software / x86 emulation), but running Firefox in a VM to work around this bug seems a little bit too intrusive :-)

Thank you for the quick fix!

Ah, that makes sense, thanks for the info.

Comment 25

[Gian-Carlo Pascutto [:gcp]]

IMHO this issue makes a great case that we need Linux aarch64 nightly/beta builds.

My understanding is that the vast majority of such systems actually use 4k pages so it is not clear it would have helped. (Not that that isn't a valid issue...)

What exact system are you on that triggered this? I understand Asahi is affected, anything else?

Comment 26

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/42c80086da44

Comment 27

[Robert Mader [:rmader]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #25)

IMHO this issue makes a great case that we need Linux aarch64 nightly/beta builds.

My understanding is that the vast majority of such systems actually use 4k pages so it is not clear it would have helped. (Not that that isn't a valid issue...)

What exact system are you on that triggered this? I understand Asahi is affected, anything else?

This specific issue should only concern Asahi, right. However:

1. Asahi / M*s seem to be gaining popularity among technical advanced Linux users pretty fast - i.e. those users most likely to run nightly, reporting issues etc. That's why I'd be be more optimistic that it would have been spotted earlier. AFAICS the M*s are well on track to becoming the best supported Linux laptops on the market and I'm regularly surprised by how common they already are in the Linux dev bubble.
2. There are a bunch of other arm64 devices appearing lately that are attractive for Firefox nightly folks - be it the Thinkpad X13s, the Raspberry Pi 5 (who's devs actively contribute to FF), new ChromeBooks (with good upstream Linux support). But they are all not covered by the official nightlies.

IMO Firefox risks losing testers/contributors from a small but, compared to its size, highly valuable group here - maybe the most Firefox-affine group out there. In any case, I just hope that issue will get addressed in a not too distant future :)

Comment 28

[Christian Holler (:decoder)]

(In reply to Robert Mader [:rmader] from comment #27)

This specific issue should only concern Asahi, right. However:

1. Asahi / M*s seem to be gaining popularity among technical advanced Linux users pretty fast - i.e. those users most likely to run nightly, reporting issues etc. That's why I'd be be more optimistic that it would have been spotted earlier. AFAICS the M*s are well on track to becoming the best supported Linux laptops on the market and I'm regularly surprised by how common they already are in the Linux dev bubble.
2. There are a bunch of other arm64 devices appearing lately that are attractive for Firefox nightly folks - be it the Thinkpad X13s, the Raspberry Pi 5 (who's devs actively contribute to FF), new ChromeBooks (with good upstream Linux support). But they are all not covered by the official nightlies.

IMO Firefox risks losing testers/contributors from a small but, compared to its size, highly valuable group here - maybe the most Firefox-affine group out there. In any case, I just hope that issue will get addressed in a not too distant future :)

Yes, we are already (and have been for a while) working on native ARM64 Linux CI (see one of the bugs linked here under "See also"). Right now, there's an issue with the cloud provider and Ubuntu that's being worked on and should be resolved soon. That will unblock creating the required worker type in Firefox CI which then will allow us to deploy the regular CI chain needed for making this an official build.

Comment 29

[Donal Meehan [:dmeehan]]

:pbone when you're ready, could you add beta and release uplift requests on this? (The bot won't ask since there are pending needinfos)

Comment 30

[Paul Bone [:pbone]]

I'm trying to verify this as fixed. I've installed Asahi on my Mac Mini, So far:

• Firefox downloaded from Mozilla's CI prior to my patch crashes immediately.
• Firefox downloaded from Mozilla's CI after my patch content processes crash pretty quickly, but I'm not getting a backtrace (yet).

And I'm having trouble building Firefox on Asahi, There's lots of little tooling things that need to be installed sepearetly or whose paths aren't set. I'm working through it but it's taking time.

Comment 31

[Paul Bone [:pbone]]

Okay, the other crash happens with --disable-phc also so it's unrelated and I can request an uplift.

Comment 32

[Paul Bone [:pbone]]

Comment on attachment 9365111 [details]
Bug 1866025 - Check if PHC is initialised on all entrypoints r=glandium

Beta/Release Uplift Approval Request

• User impact if declined: Firefox has a startup crash on Linux on anything with a page size that's not 4K. Most notably is probably Linux running on Apple Silicon.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The problem & patch are easy to understand. They avoid a null-pointer dereference when PHC failed to initialise.
• String changes made/needed: None
• Is Android affected?: No

Comment 33

[Paul Bone [:pbone]]

Comment on attachment 9365111 [details]
Bug 1866025 - Check if PHC is initialised on all entrypoints r=glandium

Beta/Release Uplift Approval Request

• User impact if declined: Firefox will crash at startup on Linux with a page size other than 4KB. Most notably that's Linux running on Apple Silicon.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The problem and fix are easy to understand. PHC's initialisation fails later causing a null pointer dereference when we assume it succeeded.
• String changes made/needed: None
• Is Android affected?: No

Comment 34

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/6d0a62974b9b

Comment 35

[Donal Meehan [:dmeehan]]

Comment on attachment 9365111 [details]
Bug 1866025 - Check if PHC is initialised on all entrypoints r=glandium

Approved for 121.0b4

Comment 36

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Comment on attachment 9365111 [details]
Bug 1866025 - Check if PHC is initialised on all entrypoints r=glandium

Approved for 120.0.1 dot release

Comment 37

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/0799a4ca860f