You are not logged in.
Hello,
As the title says, I upgrade the entire system two days ago, and once again today, and since these upgrades Firefox crashes on certain web pages.
I have gone through the usual recommended troubleshooting:
- Created new profile, no difference
- Disabled all addons, no difference
- Started with --safe-mode, firefox didn't crash
This led me to the possibility that the "Use Hardware Acceleration" option could cause the crash. Indeed, with that option disabled, the same webpages don't crash.
Well, but without the hardware acceleration any "motion" on a website, including scrolling, is very choppy.
So I went ahead and downgraded Firefox to the last version that I had no issues with (124).
And the problem is... it's also crashing.
So I suspect it must be a dependency upgrade that causes this crash. I am a bit lost now, don't really know where or what to look for.
journalctl -f did not reveal anything. Starting firefox from the command line shows these errors:
ATTENTION: default value of option mesa_glthread overridden by environment.
ATTENTION: default value of option mesa_glthread overridden by environment.
ExceptionHandler::GenerateDump cloned child 29448
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
Exiting due to channel error.
Exiting due to channel error.
This is one website where it always crashes, but there are others like it: https://www.groupe-ratheau.com/ -- works just fine in Chrome.
Any hints would be greatly appreciated!
P.S.: Decided to check my Waterfox installation, it has the same issue.
Last edited by drtebi (2024-06-21 11:06:54)
Offline
ATTENTION: default value of option mesa_glthread overridden by environment.
What about putting that back?
What gfx hardware and drivers?
Last edited by Maniaxx (2024-06-20 23:39:46)
sys2064
Offline
ATTENTION: default value of option mesa_glthread overridden by environment.
that is normal and has no relation to the crash .
firefox devs and mesa devs disagree about the usage of threaded GL, so firefox devs disable it unconditionally for firefox .
I agree we need to know more about the graphics hw & drivers.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I have looked for an answer to the mesa_gltread warning, and apparently it is a warning that can be safely ignored... at least that's what a mozilla post said.
I am using a radeon video card. I am not quite sure which drivers I would have to try to set back. It's the open source radeon driver. I suppose I can try to find out what the name of the package is and set that back?
Offline
I believe I have the following packages installed to make my video card work:
xf86-video-ati
mesa-vdpau
libva-mesa-driver
Video card is an AMD Radeon 5800 HD
Last edited by drtebi (2024-06-21 09:56:59)
Offline
There are reports of bugs in mesa with the radeon kernel driver that get driven by radeon_si.
Do things stabilize if you downgrade mesa to 24.0.8 ?
Offline
Fantastic, that did it:
sudo pacman -U mesa-1:24.0.4-2-x86_64.pkg.tar.zst
Didn't have the 24.0.8 version available, but the 24.0.4-2 version did the trick. Updated firefox to 127 again, no crashes.
Thank you so much for your help, marking the post as solved... if the next big update will make firefox crash again, I now know what to downgrade.
Offline
You'd ideally get yourself a proper backtrace and report this to mesa so it can get fixed: https://wiki.archlinux.org/title/Core_d … _core_dump
Last edited by V1del (2024-06-21 14:10:34)
Offline
You'd ideally get yourself a proper backtrace and report this to mesa so it can get fixed: https://wiki.archlinux.org/title/Core_d … _core_dump
I've never done a backtrace, but I'll try to figure it out.
Offline
OK, someone let me know if I am doing this correctly please:
I followed instructions from https://wiki.archlinux.org/title/Debugg … ing_traces
I do have a backtrace now, but since I don't know how to start mesa separately... I did run firefox until it crashed.
So I have a firefox backtrace, should I submit a bug report to mesa with this? Shouldn't it be submitted to firefox?
Or is there a way to just trace mesa separately?
Offline
The link V1del posted has instructions how to convert a kernel core dump to a backtrace usable for troubleshooting .
Not all crashes cause kernel core dumps, and in those cases the link you followed gives instrucions how to get usable backtraces.
Your crashes were due to changes in mesa and have a 99.999% chance of generating coredumps.
Please follow the link V1del posted and submit the backtrace it generates to mesa devs.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
OK, so if I understand correctly, I should install gdb and then do this:
firefox &
pgrep firefox
gdb -p 8160
When doing that it tells me...
Attaching to process 8160
ptrace: Operation not permitted.
I checked the PID again, it was correct.
From what I can find on the 'net, it seems that there is already another ptrace attached to that process. Possibly from Enlightenment (which is my desktop environment)?
P.S.: mesa was updated again, but it unfortunately didn't fix my crashing of firefox problem.
Last edited by drtebi (2024-06-23 21:35:17)
Offline
install gdb : yes .
run firefox : no .
You have to identify the coredump that correspondents with the crash .
There are several ways to do that, the simplest is to reproduce the crash .
then run (as root)
# coredumpctl info firefox
After verifying that the info is indeed from the crash, run (as root)
# coredumpctl debug firefox
that will start gdb with the specfiic coredump.
Once gdb has finished starting, you'll see a (gdb) prompt .
at that prompt you type thread apply all backtrace full to create a backtrace.
Save that backtrace and post it somewhere public so we can see it.
(it will likely be large, use https://wiki.archlinux.org/title/List_o … ted_client )
the backtrace will probably have lots of question marks, by installing needed debug packages and regenerating the backtrace those can be replaced by useful info.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
OK, I tried that, but when running (as root)
# coredumpctl info firefox
I get...
No coredumps found.
I did this right after running firefox and reproducing the crash.
Maybe it just doesn't give me a coredump? I get the "Firefox Crash Reporter" window, and after that this popup message from enlightenment:
Offline