Fedora Account System
Red Hat Associate
Red Hat Customer
The new build of Firefox (firefox-113.0-1.fc39) crashes immediately on startup, on GNOME and KDE and directly on top of with `startx`, in openQA and in local testing on my laptop. Reproducible: Always Steps to Reproduce: 1. Update to firefox-113.0-1.fc39 2. Launch Firefox Actual Results: The window never appears, Firefox crashes immediately. Expected Results: Firefox should run. See attached backtrace.
Created attachment 1963636 [details] backtrace of the crash (crashing thread only, gdb fails to generate an all thread bt)
Requested it be untagged from f39 for now: https://pagure.io/releng/issue/11421
Crashes in Rust code.
I saw firefox-113.0-1.fc39 crash when starting in Fedora-KDE-Live-x86_64-Rawhide-20230509.n.0.iso with the same kind of trace. rust-1.69.0-3.fc39 looks to have been rebuilt with llvm-16.0.2-1.fc39 by https://src.fedoraproject.org/rpms/rust/c/777115da9e2892eb47502c8afcbe2b7742b14879?branch=rawhide Since the crash doesn't happen with firefox-113.0-1.fc38 where rust-1.69.0-2.fc38 was rebuilt with llvm 15.0.7 and the crash involved Rust, there might be some problem with rust-1.69.0-3.fc39 and llvm 16.0.2.
Tentatively moving to Rust to get compiler people in touch.
This doesn't narrow down much, but according the backtrace, the atomic_load is getting a bogus pointer 0x1: #5 core::sync::atomic::atomic_load<usize> (dst=0x1, order=core::sync::atomic::Ordering::Relaxed) at /builddir/build/BUILD/rustc-1.69.0-src/library/core/src/sync/atomic.rs:3160 No locals. #6 core::sync::atomic::AtomicUsize::load (self=0x1, order=core::sync::atomic::Ordering::Relaxed) at /builddir/build/BUILD/rustc-1.69.0-src/library/core/src/sync/atomic.rs:2263 No locals. #7 servo_arc::{impl#10}::clone<indexmap::map::IndexMap<style::gecko_string_cache::Atom, servo_arc::Arc<style::custom_properties::VariableValue>, core::hash::BuildHasherDefault<style::selector_map::PrecomputedHasher>>> (self=0x7fa1840bc950) at servo/components/servo_arc/lib.rs:402 old_size = <optimized out> That &self (&Arc) looks plausible, but then that should contains a pointer to the heap-allocated `ArcInner`, which starts with the atomic counter in question.
Note that this isn't a standard Arc but a custom fork of the one from the standard library ... Which is also separately packaged for Fedora as "rust-servo_arc": https://github.com/servo/servo/tree/master/components/servo_arc (not sure if this is still the same one used by Firefox)
*** Bug 2203248 has been marked as a duplicate of this bug. ***
Same with 113.0.1, I will need to get that untagged too. Can we maybe set Firefox to build with LLVM 15 for now on Rawhide, if that will fix this, so its Firefox doesn't get really old?
Linked a few bugs -- the two Rust bugs provide context, but per the Mozilla bug this is really a Firefox issue. It looks like there are a few fixes available, so perhaps you can backport those?
Thanks, will look at it.
firefox-113.0.1-2.fc39 is still broken, looks like it was built by someone else who maybe wasn't aware of this. jgrulich, please don't build Firefox for Rawhide until this is addressed somehow - every time it gets built ATM we have to untag it because it doesn't work.
Is this resolved in firefox-113.0.1-4.fc39? I see that it has survived almost a week without getting untagged... (Rust 1.70 comes out this week, and I would like to let f38 go back to llvm-16 as well in the new builds.)
ah, yes, it seems to be. The changelog indicates it: - Added patches from 113.0.2 - Added Rust fix for Rawhide (mzbz#1831242). and openQA tests are passing. Martin did apply the same patches to f38 Firefox, it seems, so it should be OK to put llvm-16 in f38 too.