I experience firefox runtime freezes since update to www-client/firefox-93.0
Issue persists with 94.0 and current 94.0.1
Similar runtime freezes are reported in 821505 where downgrading to llvm<13 and rust<1.56.1 helps.
I can confirm that if I only downgrade rust package to rust-1.55.0 (keep everything else unchanged, including llvm-13.0.0) and rebuild firefox, then firefox does not freeze anymore.
Steps to Reproduce:
Exact usage pattern is not known yet, but I see runtime freeze reloading a couple of heavy sites in tabs.
Created attachment 749139 [details]
I can confirm the bug and the workaround.
Additionally to the freezes a Bigbluebutton website could not find a speaker.
This is usefull as indicator for the bug, because it is easy to trigger.
Indeed, freezes fixed by rebuilding firefox with <rust-1.56
An other way to trigger it: just open a jitsi meeting, it freezes the whole firefox after some seconds.
It seems that debian has the same issue : https://email@example.com/msg1827894.html
I am seeing the problems described in this bug and have now rebuilt firefox-94.0.1 with rust-1.55 (itself built with llvm-13.0), rather than rust 1.56.1.
Unfortunately, this has not fixed things and I've had to revert to 93.0 (which itself was built with the same rust-1.55/llvm-13.0 combination).
The fix described at https://bugzilla.mozilla.org/show_bug.cgi?id=1740260 - setting gfx.x11-egl.force-disabled to true - was not effective (and would be disappointing to have to do as egl is one of the major features of the 94 release).
I don't know how typical my experience might be - nor how to get around it atm :-( - but my system is old with no hardware GPU acceleration so I guess this could be an issue.
The only other comment I have atm is that a 'Rust Update Policy' is published at
where 94 'uses' rust 1.55, with rust 1.56 being flagged for firefox 95.
Any tips appreciated, thanks
Huh, this is interesting, because for me, Rust 1.55 (built with llvm 13) did fix all the issues even in Firefox 94.0.1 (which I wrote about in the dependant bug: https://bugs.gentoo.org/821898#c4 ).
(Force-disabling egl didn't do any difference for me either way in any combination. I suspect the issue here is not graphics related at all, but rather IPC or thread synchro.)
If for you, 94.0.1 itself is a problem, no matter the Rust version, maybe this is yet another separate issue? Or maybe this is even more complex than just "Rust 1.60 b0rked".
rust-1.55 forcibly uses llvm12, system or bundled, or did you change the ebuild?
Oh, okay, I didn't know that, my bad.
No, I haven't changed the ebuild. I rescind my claim that I have built rust 1.55 with llvm 13, then, sorry.
(In reply to Georgy Yakovlev from comment #6)
> rust-1.55 forcibly uses llvm12, system or bundled, or did you change the
No I do not think so:
# emerge -av --depclean rust llvm
Calculating dependencies... done!
dev-lang/rust-1.55.0 pulled in by:
virtual/rust-1.55.0 requires ~dev-lang/rust-1.55.0[abi_x86_32(-),abi_x86_64(-)]
sys-devel/llvm-13.0.0 pulled in by:
dev-lang/spidermonkey-78.15.0 requires sys-devel/llvm:13
media-libs/mesa-21.3.0_rc3 requires <sys-devel/llvm-14:=[abi_x86_32(-),abi_x86_64(-),llvm_targets_AMDGPU(-)], sys-devel/llvm:13[abi_x86_32(-),abi_x86_64(-),llvm_targets_AMDGPU(-)], <sys-devel/llvm-14:13/13=[abi_x86_32(-),abi_x86_64(-),llvm_targets_AMDGPU(-)]
sys-devel/clang-13.0.0 requires ~sys-devel/llvm-13.0.0[llvm_targets_AMDGPU], ~sys-devel/llvm-13.0.0:13/13=[-debug,abi_x86_32(-),abi_x86_64(-)], ~sys-devel/llvm-13.0.0[llvm_targets_BPF], ~sys-devel/llvm-13.0.0[llvm_targets_NVPTX], ~sys-devel/llvm-13.0.0:13=[-debug,abi_x86_32(-),abi_x86_64(-)], ~sys-devel/llvm-13.0.0[llvm_targets_X86]
sys-devel/lld-13.0.0 requires ~sys-devel/llvm-13.0.0
sys-devel/llvmgold-13-r1 requires sys-devel/llvm:13[gold(-)]
sys-libs/compiler-rt-13.0.0 requires >=sys-devel/llvm-6
sys-libs/compiler-rt-sanitizers-13.0.0 requires >=sys-devel/llvm-6
www-client/firefox-94.0.1 requires sys-devel/llvm:13
>>> No packages selected for removal by depclean
The bug has been closed via the following commit(s):
Author: Thomas Deutschmann <firstname.lastname@example.org>
AuthorDate: 2021-11-09 20:51:51 +0000
Commit: Thomas Deutschmann <email@example.com>
CommitDate: 2021-11-09 20:53:32 +0000
www-client/firefox: fix runtime errors
Package-Manager: Portage-3.0.28, Repoman-3.0.3
Signed-off-by: Thomas Deutschmann <firstname.lastname@example.org>
www-client/firefox/Manifest | 100 +-
...efox-94.0.1.ebuild => firefox-94.0.1-r1.ebuild} | 2 +-
www-client/firefox/firefox-94.0.ebuild | 1209 --------------------
3 files changed, 2 insertions(+), 1309 deletions(-)
For those curious what the patchset update actually adds, as I was:
Heh, okay, that fits with my observations with regards to pulse and thread synchronization. Great find, thanks!
(I do wonder why profiler.firefox.com also broke, even without running pulse. Maybe that's even a different issue, tho. I'll see if that's still an issue when I have rebuild rust-1.56.1 and then Firefox.)
If I'm not mistaken, the same bug occurs on =www-client/firefox-91.3.0 as well, and would need a fix there too.
Firefox ESR 91.4 will get a patch for this (this version is on a different cubeb version). I need to check if I can backport.
Created attachment 756124 [details]
Seemingly working cubeb patches for firefox 91.3.0
I've tried to get the changes over to 91.3.0, and the outcome is attached.
Up to now my Firefox install seems to build and work fine with those patches and Rust 1.56.1.
The patch files are just the ones from the non-ESR Firefox ebuild, with some small changes to make them apply against 91.3.0. I didn't bother fixing file checksums or hunks/fuzz, as I just wanted to get firefox 91.3.0 working on my system without needing a Rust downgrade...
Andreas, thanks for the patch, it works for me
Can an updated ebuild with this patch be created? My Firefox needs to be rebuilt because of some dependency having changed, I think it was boost. It doesn't because of this issue, likely, because I'm using pgo. Now I'm afraid to restart my system and have my old Firefox become broken…
I think this is occurring for 94.0.2 now too
Fix landed in 91.4.0esr. I am closing this one because upstream believes that all issues caused by rust-1.56.1 have been fixed.
If someone believes there is still a problem left which is caused by rust-1.56.1, please file a new bug and make sure you tested with <rust-1.56.1 and provide steps how to reproduce.