You need a LOT of RAM to run firefox under gdb.
I recall that 32GiB had was not enough.
1 Like
@barryascott, thanks for that. I merely have 30.5 GiB of DDR5 SDRAM available (and no swap, since Fedora doesn’t create swap by default, and I’m not technically competent enough yet to add it myself - see responses to How to create a swap file with dynamic/unbounded size?) and I’m not willing to replace it for my still-potentially-too-little 64 GiB of DDR4 SDRAM, so perhaps I’ll just reinstall.
@fche, sorry - should have run file on it. Dumb of me. However, would it be wise to neglect the setup process defined in the script? I’m surprised that gdb seems not to cope with shell scripts that invoke binaries, since it renders it fairly useless when trying to accurately diagnose steam or firefox (since the absence of protections in the script could feasibly cause other issues).
Indeed, although why? I don’t believe you explained what that might change. Do you estimate that it’s unable to download symbols due to lack of permissions?
In my testing here, gdb -args /bin/sh /usr/bin/firefox does eventually latch onto the real binary. Yeah I’m sure it takes lots of RAM. Why did you want to debug Firefox anyway - what are you trying to do?
Regarding sudo, never mind, not relevant to your situation. (Sometimes one wants to debug a process running under someone else’s userid; in that case, sudo -E is a way of letting gdb operate smoother with debuginfod.)
1 Like
@fche, per the rather lengthy context of How to install `debuginfo` package requested by GDB that doesn't exist in repositories? - #17 by rokejulianlockhart, I’d like to get useful stack traces for the 50% of reports crash reports for pixbuf2 I get whenever I use the file picker portal (via Firefox or Chrome).
OK, to process an older core dump. Yes, debuginfod-informed gdb instances should do just fine with such files, even if they contain residue of shared libraries that have long been updated.
1 Like
By the way, it’s a long shot, but it’s worth trying:
% eu-stack -v --core=COREFILE
This too can use debuginfod downloading, but is perhaps less heavy than gdb, just for generating a traceback.
1 Like
@barryascott, I’ve now exactly the same problem again, except that this time, it’s for a package that has very recently regained its debuginfo counterpart: [1]
RokeJulianLockhart@Beedell:~$ abrt report 2edadf7 Reporting problem 2edadf7 no actions matching this problem found for event 'collect_GConf' no actions matching this problem found for event 'collect_vimrc_system' no actions matching this problem found for event 'collect_vimrc_user' no actions matching this problem found for event 'collect_xsession_errors' ('report_uReport' completed successfully) Generating backtrace Backtrace is generated and saved, 173423 bytes Looking for similar problems in bugzilla Reporting is disabled because the generated backtrace has low informational value. Please try to install debuginfo manually using the command: "dnf debuginfo-install chromium-141.0.7390.76-1.fc42" and try again. RokeJulianLockhart@Beedell:~$ abrt info 2edadf7 Id 2edadf7 Component chromium Count 1 Time 2025-10-18 12:23:38 Command line $'/usr/lib64/chromium-browser/chromium-browser --enable-chrome-browser-cloud-management --enable-features=AllowQt,WaylandLinuxDrmSyncobj,WaylandPerSurfaceScale,WaylandUiScale,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,AcceleratedVideoEncoder --enable-plugins --enable-extensions --enable-user-scripts --enable-printing --enable-sync --auto-ssl-client-auth' Package chromium-141.0.7390.76-1.fc42 User id 1000 (RokeJulianLockhart) Path /var/spool/abrt/ccpp-2025-10-18-12:23:38.354200-43650 Reported to ABRT Server https://retrace.fedoraproject.org/faf/reports/bthash/6223aaeeb54d9a2aeac4a0ff0af1afde40cb2818
I have managed to install one of the requested debuginfo packages that exists:
RokeJulianLockhart@Beedell:~$ dnf5 history info 113 Transaction ID : 113 Begin time : 2025-10-20 22:20:02 Begin rpmdb : bb84b99dd595d5104dc4704911ce535c44405f5bf185392f9dc8d58fb50491fd End time : 2025-10-20 22:20:03 End rpmdb : d69d6607ad16488ccafef9a1d6ee73b924cdb2ed29adb3cc8be0ad6dbe2bac2a User : 1000 Mr. Roke Julian Lockhart Beedell (RJLB) <RokeJulianLockhart> Status : Ok Releasever : 42 Description : dnf5 --enablerepo=*debug* install libopenmpt-debuginfo-0.8.3-1.fc42.x86_64 Comment : Packages altered: Action Package Reason Repository Install libopenmpt-debuginfo-0:0.8.3-1.fc42.x86_64 User updates-debuginfo Install libopenmpt-debugsource-0:0.8.3-1.fc42.x86_64 Weak Dependency updates-debuginfo
…alongside chromium-debuginfo-141.0.7390.107-1.fc42.x86_64:
RokeJulianLockhart@Beedell:~$ dnf5 history info 114 Transaction ID : 114 Begin time : 2025-10-20 22:25:42 Begin rpmdb : d69d6607ad16488ccafef9a1d6ee73b924cdb2ed29adb3cc8be0ad6dbe2bac2a End time : 2025-10-20 22:25:48 End rpmdb : 3e77aa389be962fe4a41c35addb6cad5c92b1bf300576ba1c3cd47c9b7855511 User : 1000 Mr. Roke Julian Lockhart Beedell (RJLB) <RokeJulianLockhart> Status : Ok Releasever : 42 Description : dnf5 --enablerepo=*debug* install chromium-debuginfo libopenmpt-debuginfo-0.8.3-1.fc42.x86_64 Comment : Packages altered: Action Package Reason Repository Install chromium-debuginfo-0:141.0.7390.107-1.fc42.x86_64 User updates-debuginfo
However, that doesn’t appear to be sufficient, even after an abrt retrace -f. [2]