Fedora Account System
Red Hat Associate
Red Hat Customer
Since I upgraded to Fedora 43, Firefox always crashes when I do any action that is linked to a file manager. Two cases that are always reproducible: 1) A PDF is opened in Firefox, so directly, not embedded in a web page (the latter was not tested). The issue occurs both when a PDF is opened from the file system and ends with .pdf in the link, but also when an Internet-link is a PDF without having the .pdf in the name. When the PDF is open, I do either CTRL + S to save the file, or I do "file" -> "save page as": in both cases, Firefox crashes immediately. 2) When I am on a website that has a button that aims to select a file to be uploaded, Firefox crashes once I click the button. Examples include the current FOSDEM aplication website when I try to upload the profile picture of the speaker or a theme picture of the talk. Another example is the "Durchsuchen" button on this page: https://www.elster.de/eportal/login/softpse While I do not know for sure, so far the file manager seems to be the constant: both types of actions lead to a crash when a type of file manager is to be opened. It might be mentioned that I experience for some weeks (so already on F42) that Firefox regularly but not always puts tabs into a new window when I click on them to just select them (or even opens a new window with a new empty tab if I just clicked to select an existing tab in an existing window) -> I exclude that I just accidentally put them sufficiently far out of the tab area to provoke that, but I didn't consider that bug sufficiently serious to report given a lack of time, and I am not sure if it is related, but I mention it as it is related to the window system. While I do not think the two are related, it might be mentioned that I also experience BZ#2403355 at Thunderbird I already tested the recent update to firefox-144.0.2-1.fc43 -> issue remains. I cannot say if that issue origins in Firefox or in KDE or so. I am happy to test new builds or configurations or so. Let me know :) Here is the error log from the website "www.elster.de/eportal/login/softpse" when I clicked the "Durchsuchen" button: ``` py0xc3@fedora:~$ firefox [Parent 43770, Main Thread] WARNING: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builddir/build/BUILD/firefox-144.0.2-build/firefox-144.0.2/toolkit/xre/nsSigHandlers.cpp:201 (org.mozilla.firefox:43770): Gtk-WARNING **: 19:30:00.192: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze/status/16@2x/image-missing.svg: Loader process exited early with status '1'Command: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/py0xc3/.cache/fontconfig" "/home/py0xc3/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "302" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "295" (gdk-pixbuf-error-quark, 0) Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze/status/16@2x/image-missing.svg: Loader process exited early with status '1'Command: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/py0xc3/.cache/fontconfig" "/home/py0xc3/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "302" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "295" (gdk-pixbuf-error-quark, 0) Redirecting call to abort() to mozalloc_abort ExceptionHandler::GenerateDump attempting to generate:/home/py0xc3/.mozilla/firefox/jcm6gadg.default-release/minidumps/0eb5d900-cb62-39da-283a-3b264ad9c569.dmp ExceptionHandler::GenerateDump cloned child 44602 ExceptionHandler::WaitForContinueSignal waiting for continue signal... ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::GenerateDump minidump generation succeeded Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. ``` Reproducible: Always Steps to Reproduce: Open any of the mentioned, or a comparable page, and click the respective button; or just try to save a PDF that is opened in Firefox with ctrl+s or "file">"save page" Actual Results: Firefox crashes Expected Results: Firefox does not crash but open the file manager to save the PDF or to select the file that the button aims to upload after being selected. Additional Information: F43 KDE Spin with confined users, just upgraded from 42. Only default software and no external modules, only default Fedora repositories: only exception is "mesa-va-drivers-freeworld" and "mesa-vdpau-drivers-freeworld" from rpmfusion-free. Up to date as of today. AMD Ryzen 7 PRO 6850U (= 6800U with some additions) with 8 cores / 16 threads and 32 GB LPDDR5 (6400 MT/s). Occurs on all kernels since upgrading to F43: 6.17.5-300.fc43.x86_64 and 6.17.6-300.fc43.x86_64. The issue remains after the recent update to firefox-144.0.2-1.fc43.
Supplement: Firefox now also crashes in other circumstances occasionally, but I cannot derive a clear pattern except at the mentioned examples. E.g., when I was on the website of Asus and selecting on the side bar which products to be shown (e.g., show notebooks with 15" and 16"): when I selected several attributes at once without waiting for them to be loaded, Firefox twice crashed as well. Given the correlations and the limited possibility to reproduce it (and as it occurs not very often in these cases), I cannot say for sure if that was introduced by the F43 upgrade (which I expect) or with firefox-144.0.2-1.fc43. I generally submit the automatically suggested reports to Mozilla when restarting, usually with a short comment. But not sure how valuable they are without further context, and if that issue is really Mozilla or Fedora-related (or even KDE (?)).
Do I understand correctly that you're using flatpak Firefox version? Can you try plain Mozilla binaries with clean profile? https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries Thanks.
Hi Martin, thanks for the support :) > Do I understand correctly that you're using flatpak Firefox version? No, I use the default Firefox from Fedora's repositories, as it is installed by default on Fedora KDE Spin (not Kinoite or so). I do not use flatpak(s) at all, nor have I installed any. Since the mentioned update, I use the following without changes in the behavior: ``` py0xc3@fedora:~$ dnf info --installed firefox Installed packages Name : firefox Epoch : 0 Version : 144.0.2 Release : 1.fc43 Architecture : x86_64 Installed size : 253.1 MiB Source : firefox-144.0.2-1.fc43.src.rpm ``` > Can you try plain Mozilla binaries with clean profile? > https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries I have tested the current upstream Firefox, as suggested on https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries -> firefox-144.0.2.tar.xz. However, the bug still occurs: once I try to do something that opens a type of file manager, Firefox crashes. This time, I tried to download again the firefox binary tar "firefox-144.0.2.tar.xz" from Mozilla. I tried both variants/commands suggested in the wiki page. When I used the firefox (so the unpacked binary of firefox-144.0.2.tar.xz) from terminal with `./firefox` I got this output including the crash: ``` py0xc3@fedora:~/Desktop/mozilla/firefox$ ./firefox [Parent 17019, Main Thread] WARNING: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201 (firefox:17019): Gtk-WARNING **: 17:34:47.046: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. ``` When I used the same binary with the command `MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote`, I got this output (in both cases I just tried to re-download the firefox-144.0.2.tar.xz file again from Mozilla): ``` py0xc3@fedora:~/Desktop/mozilla/firefox$ MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote [Parent 24617, Main Thread] WARNING: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201 (firefox:24617): Gtk-WARNING **: 17:38:59.245: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. [Parent 24617, Main Thread] WARNING: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201 (firefox:24617): Gtk-WARNING **: 17:39:03.950: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze/status/16@2x/image-missing.svg: Loader process exited early with status '1'Command: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/py0xc3/.cache/fontconfig" "/home/py0xc3/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "190" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "189" (gdk-pixbuf-error-quark, 0) Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/breeze/status/16@2x/image-missing.svg: Loader process exited early with status '1'Command: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/py0xc3/.cache/fontconfig" "/home/py0xc3/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/py0xc3/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "190" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "189" (gdk-pixbuf-error-quark, 0) Redirecting call to abort() to mozalloc_abort ExceptionHandler::GenerateDump attempting to generate:/home/py0xc3/.mozilla/firefox/izdoe75f.default-release-1/minidumps/68af31ad-207d-d442-d73d-fe1888ccbf3d.dmp ExceptionHandler::GenerateDump cloned child ExceptionHandler::WaitForContinueSignal waiting for continue signal... 25992 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::GenerateDump minidump generation succeeded Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. Exiting due to channel error. ``` Actually, the upstream Firefox binaries are worse than the default Firefox from Fedora's repository because additionally to the crash issue, it has severe/noteworthy performance issues comparable to those that I have & reported in Thunderbird in my last post in BZ#2403355 (so the performance issues I have since upgrading to F43). So just moving the cursor over buttons in the settings in Firefox (without clicking anything), it takes 1-2 seconds before the machine is able to change the background of the very button to illustrate that the cursor is upon this setting: while I have the subjective perception that the default Firefox build of Fedora also has decreased performance since upgrading to F43, it is not as severe as TB or now the upstream Firefox builds. The new tests are done on 6.17.6-300.fc43.x86_64, AMD Ryzen 7 PRO 6850U with 8 cores / 16 threads and 32 GB LPDDR5 (6400 MT/s). F43 KDE Spin. Up to date with `dnf update` as of today. ----- I will also add a post in BZ#2403355 after testing the upstream Thunderbird.
These are two exemplary crash reports from Fedora's default Mozilla Firefox [1] that I already submitted earlier: https://crash-stats.mozilla.org/report/index/646173b8-e301-4784-9162-4b5f80251105 https://crash-stats.mozilla.org/report/index/91e2833d-737b-435f-9b8a-4fa860251103 The following one I just created with the upstream Firefox build (the firefox-144.0.2.tar.xz binary opened with `./firefox`): https://crash-stats.mozilla.org/report/index/e627c5b4-97cf-4c4d-a181-2dca10251105 ----------- [1] So this one (default Fedora build, no flatpak or upstream build): ``` py0xc3@fedora:~$ dnf info --installed firefox Installed packages Name : firefox Epoch : 0 Version : 144.0.2 Release : 1.fc43 Architecture : x86_64 Installed size : 253.1 MiB Source : firefox-144.0.2-1.fc43.src.rpm ```
That crashes comes deep from system library (gtk3), not firefox itself. I wonder what may cause it. The only way how to get any info from the crashes is to use local debugging: https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_local_debugging Please try the gdb way: https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Running_application_in_debugger I'm not sure if coredumpctl catches reports submitted to Mozilla https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_coredumpctl_to_get_backtrace You can check 'coredumpctl list' terminal command if there's any Firefox crash - if so you can also use coredumpctl to get the local crash data instead of direct gdb debugging. Thnaks.
If you have sent the report to upstream using crash report dialog, check the about:crashes and send a link to the reports. I suspect it could be introduced by prefer file portals instead of native dialogs. Please try to set widget.use-xdg-desktop-portal.file-picker to 0 in about:config.
> The only way how to get any info from the crashes is to use local debugging: > https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_local_debugging > > Please try the gdb way: > https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Running_application_in_debugger > > I'm not sure if coredumpctl catches reports submitted to Mozilla > https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_coredumpctl_to_get_backtrace I had gdb already installed, and did `dnf debuginfo-install firefox` with root, and installed the related packages, before going ahead with the following. As you anticipated, the "coredumpctl list" did not document the crashes :( However, I am not sure if the command for gdb "firefox -g -d gdb" in our wiki is obsoleted / no longer applicable? "man firefox" indicates that "-d gdb" is not a valid option, and if I try "firefox -g -d gdb" in the command line, firefox opens and tries to open the website "http://gdb/" and if I then provoke the crash, I end up on the normal command line, not gdb. The upstream Docs (https://firefox-source-docs.mozilla.org/contributing/debugging/debugging_firefox_with_gdb.html#how-to-debug-firefox-with-gdb) contain different commands but seem to presume I have a python tool called "mach" available, but I am not sure if that is up to date either: no indication how to get that, it is not in the downloaded upstream archives/files. I only find a PyPI package of "mach" that is not updated for over 6 years (https://pypi.org/project/mach/) and that seems to be not from the original maintainer of the tool, and its upstream link to "mach" of Mozilla does no longer exist (https://developer.mozilla.org/en-US/docs/Developer_Guide/mach). The upstream Docs of Firefox indicate that using gdb "traditionally" just by attaching to firefox will not be useful due to its child processes' having separated sandboxing (thus referring to creating a solution with "mach"). If I try "gdb firefox" or "gdb /usr/bin/firefox", I end up with the gdb output: ``` Type "apropos word" to search for commands related to "word"... "/usr/bin/firefox": not in executable format: file format not recognized (gdb) run Starting program: No executable file specified. Use the "file" or "exec-file" command. (gdb) ``` Since that did not work, I gave the attaching to child processes a shot, and I did start firefox (ptrace_scope was disabled, 0, during the test), then attached gdb to the parent process, continued, then created a new tab to use it to provoke the crash through a download, then I attached another gdb to the very child in which I attempt the download, continued, and then I provoked the crash: in the below pastebins are the gdb outputs of the parent and the child (1 week pastebin): Firefox parent, pid60154: https://pastebin.com/0n3PD52R Child that attempted download of a file, pid60787: https://pastebin.com/2kF4Lch5 Keep in mind that I did not really use gdb for 10 years, and never used it thoroughly, so I might formulate/use inappropriate commands or ways of use gdb. Not sure what your preferred way of using gdb is in that situation? > If you have sent the report to upstream using crash report dialog, check the about:crashes and send a link to the reports. I did in my last post -> https://bugzilla.redhat.com/show_bug.cgi?id=2412225#c4 , or do you ask for more links of earlier crashes? > Please try to set widget.use-xdg-desktop-portal.file-picker to 0 in about:config. I tried, but the outcome is the same. Here is the related report with widget.use-xdg-desktop-portal.file-picker = 0: https://crash-stats.mozilla.org/report/index/4a4d2388-7f38-4b53-adc2-9bacd0251106 I reset to the default value "2" for now (but I am happy to test more with "0" if you think it's worth for further testing of course). The gdb test took place with the default "2".
I learned in the recent days that Firefox also crashes sometimes on normal websites, so without involving file managers or downloads or so. It's not as easy to reproduce though. Here is a crash report from Firefox of a case in which I was on a website and it crashed (I think I was just clicking on something within the website at the very moment of the crash): https://crash-stats.mozilla.org/report/index/2936fcf7-2e9a-4c90-9e94-370150251109#tab-details
Similar crash occurs with QCAD: https://bugzilla.redhat.com/show_bug.cgi?id=2413638 $ qcad Warning: custom default action class not found: scripts/Pro/DefaultActionPro.js Warning: custom default action class not found: scripts/Pro/DefaultActionPro.js (qcad-bin:156708): Gtk-WARNING **: 19:45:35.744: Could not load a pixbuf from icon theme. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Luv/actions/22/image.svg: Could not spawn the following command. Is the used binary available? `"bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/sagitter/.cache/fontconfig" "/home/sagitter/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "41" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "40"`: No such file or directory (os error 2) (gdk-pixbuf-error-quark, 0) Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Luv/actions/22/image.svg: Could not spawn the following command. Is the used binary available? `"bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try" "/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try" "/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try" "/home/sagitter/.cache/fontconfig" "/home/sagitter/.cache/fontconfig" "--ro-bind-try" "/usr/lib/fontconfig/cache" "/usr/lib/fontconfig/cache" "--bind-try" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--setenv" "XDG_CACHE_HOME" "/home/sagitter/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg" "--seccomp" "41" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd" "40"`: No such file or directory (os error 2) (gdk-pixbuf-error-quark, 0) /usr/bin/qcad: line 3: 156708 Aborted (core dumped) /usr/lib64/qcad/qcad-bin "$@"
Do you have the gdk-pixbuf2-modules-extra package(s) installed? I have found interactions between various image file formats and glycin-loaders in the past which might have been due to problems of this sort before these modules-extra packages became available. I have not seen any of these crashes with Firefox in a long time since I installed them.
> Do you have the gdk-pixbuf2-modules-extra package(s) installed? No. I will install it from the default repos and test later, and post about if it makes a difference. -------- I identified another indication that BZ#2412225 and BZ#2403355 might be the same issue, or at least overlapping: I have not used this function for long, but today I wrote an email with thunderbird and wanted to attach a file: at the moment I clicked this, it took the usual 2-3 seconds to process the click, and then thunderbird crashed -> so it crashed the moment a file manager should have opened to select the file that was to be attached.
> Do you have the gdk-pixbuf2-modules-extra package(s) installed? > > No. I will install it from the default repos and test later, and post about if it makes a difference. I installed it, and then I rebooted to ensure that the testing condition is not corrupted by any means: but the issue remains as usual. I tested by opening a PDF and once it was opened, I tried to download it with CTRL+S, as the issue is 100% reproducible in this case: once the file manager should have opened to select where to store the file, Firefox crashes.
Update to 145 does not change the issue: https://crash-stats.mozilla.org/report/index/62fb5e61-5534-435a-8506-bad370251113 But I presume it is no longer considered most likely the issue origins in Firefox anyway. I'm now on ``` Name : firefox Epoch : 0 Version : 145.0 Release : 2.fc43 Architecture : x86_64 Installed size : 289.6 MiB Source : firefox-145.0-2.fc43.src.rpm From repository : updates ```
Is someone working on this at the moment? I am aware that this issue is not widespread and therefore other issues might be more urgent, so I can understand if maintainers have to emphasize other tickets, but it would be good to know if that is the case and therefore if I need to find alternatives, as BZ#2412225 and BZ#2403355 are seriously hindering my workflow.
Taking backtrace from https://bugzilla.redhat.com/show_bug.cgi?id=2413638 so looks like bug in Gtk3: ``` Stack trace of thread 19907: #0 0x00007fe1c58803cc __pthread_kill_implementation (libc.so.6 + 0x743cc) #1 0x00007fe1c582618e raise (libc.so.6 + 0x1a18e) #2 0x00007fe1c580d6d0 abort (libc.so.6 + 0x16d0) #3 0x00007fe1c38ac482 g_assertion_message.cold (libglib-2.0.so.0 + 0x2482) #4 0x00007fe1c391f362 g_assertion_message_error (libglib-2.0.so.0 + 0x75362) #5 0x00007fe1b0f4f389 ensure_surface_for_gicon (libgtk-3.so.0 + 0x14f389) #6 0x00007fe1b0f4fa73 _gtk_icon_helper_get_size (libgtk-3.so.0 + 0x14fa73) #7 0x00007fe1b0f632a3 gtk_image_get_content_size (libgtk-3.so.0 + 0x1632a3) #8 0x00007fe1b0ea2566 gtk_css_custom_gadget_get_preferred_size (libgtk-3.so.0 + 0xa2566) #9 0x00007fe1b0ea70ef gtk_css_gadget_get_preferred_size (libgtk-3.so.0 + 0xa70ef) #10 0x00007fe1b0f5c04b gtk_image_get_preferred_width.lto_priv.0 (libgtk-3.so.0 + 0x15c04b) #11 0x00007fe1b10337de gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x2337de) #12 0x00007fe1b1034476 gtk_widget_get_preferred_width (libgtk-3.so.0 + 0x234476) #13 0x00007fe1b0e4b78d gtk_box_get_content_size (libgtk-3.so.0 + 0x4b78d) #14 0x00007fe1b0ea2566 gtk_css_custom_gadget_get_preferred_size (libgtk-3.so.0 + 0xa2566) #15 0x00007fe1b0ea70ef gtk_css_gadget_get_preferred_size (libgtk-3.so.0 + 0xa70ef) #16 0x00007fe1b0e41e2b gtk_box_get_preferred_width.lto_priv.0 (libgtk-3.so.0 + 0x41e2b) #17 0x00007fe1b10337de gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x2337de) #18 0x00007fe1b1034476 gtk_widget_get_preferred_width (libgtk-3.so.0 + 0x234476) #19 0x00007fe1b10337de gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x2337de) #20 0x00007fe1b1034476 gtk_widget_get_preferred_width (libgtk-3.so.0 + 0x234476) #21 0x00007fe1b0e443c0 gtk_bin_get_preferred_width (libgtk-3.so.0 + 0x443c0) #22 0x00007fe1b100e58b gtk_revealer_real_get_preferred_width (libgtk-3.so.0 + 0x20e58b) #23 0x00007fe1b10337de gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x2337de) #24 0x00007fe1b1034476 gtk_widget_get_preferred_width (libgtk-3.so.0 + 0x234476) #25 0x00007fe1b0ea2566 gtk_css_custom_gadget_get_preferred_size (libgtk-3.so.0 + 0xa2566) #26 0x00007fe1b0ea70ef gtk_css_gadget_get_preferred_size (libgtk-3.so.0 + 0xa70ef) #27 0x00007fe1b0f7982f gtk_list_box_row_get_preferred_width (libgtk-3.so.0 + 0x17982f) #28 0x00007fe1b10337de gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x2337de) #29 0x00007fe1b1034476 gtk_widget_get_preferred_width (libgtk-3.so.0 + 0x234476) #30 0x00007fe1b0f804bf gtk_list_box_measure (libgtk-3.so.0 + 0x1804bf) #31 0x00007fe1b0ea2566 gtk_css_custom_gadget_get_preferred_size (libgtk-3.so.0 + 0xa2566) #32 0x00007fe1b0ea70ef gtk_css_gadget_get_preferred_size (libgtk-3.so.0 + 0xa70ef) #33 0x00007fe1b0f8063f gtk_list_box_measure (libgtk-3.so.0 + 0x18063f) #34 0x00007fe1b0ea2566 gtk_css_custom_gadget_get_preferred_size (libgtk-3.so.0 + 0xa2566) #35 0x00007fe1b0ea70ef gtk_css_gadget_get_preferred_size (libgtk-3.so.0 + 0xa70ef) #36 0x00007fe1b0f796c2 gtk_list_box_get_preferred_height (libgtk-3.so.0 + 0x1796c2) #37 0x00007fe1b1033929 gtk_widget_query_size_for_orientation (libgtk-3.so.0 + 0x233929) #38 0x00007fe1b1034529 gtk_widget_get_preferred_height (libgtk-3.so.0 + 0x234529) #39 0x00007fe1b10e67be viewport_set_hadjustment_values (libgtk-3.so.0 + 0x2e67be) #40 0x00007fe1b10e6b7c viewport_set_adjustment (libgtk-3.so.0 + 0x2e6b7c) #41 0x00007fe1c2eef058 object_set_property (libgobject-2.0.so.0 + 0x18058) #42 0x00007fe1c2ef24cd g_object_set_valist (libgobject-2.0.so.0 + 0x1b4cd) #43 0x00007fe1c2ef299b g_object_set (libgobject-2.0.so.0 + 0x1b99b) #44 0x00007fe1b10197ea gtk_scrolled_window_set_hadjustment (libgtk-3.so.0 + 0x2197ea) #45 0x00007fe1c2eef1bf object_set_property (libgobject-2.0.so.0 + 0x181bf) #46 0x00007fe1c2eefa18 g_object_new_internal.part.0 (libgobject-2.0.so.0 + 0x18a18) #47 0x00007fe1c2ef1283 g_object_newv (libgobject-2.0.so.0 + 0x1a283) #48 0x00007fe1b0e536cc _gtk_builder_construct (libgtk-3.so.0 + 0x536cc) #49 0x00007fe1b0e53cff builder_construct (libgtk-3.so.0 + 0x53cff) #50 0x00007fe1b0e54b41 start_element (libgtk-3.so.0 + 0x54b41) #51 0x00007fe1c38ef9c9 emit_start_element (libglib-2.0.so.0 + 0x459c9) #52 0x00007fe1c38f3b6e g_markup_parse_context_parse (libglib-2.0.so.0 + 0x49b6e) #53 0x00007fe1b0e50d40 _gtk_builder_parser_parse_buffer (libgtk-3.so.0 + 0x50d40) #54 0x00007fe1b0e51642 gtk_builder_extend_with_template (libgtk-3.so.0 + 0x51642) #55 0x00007fe1b1100bfd gtk_widget_init_template (libgtk-3.so.0 + 0x300bfd) #56 0x00007fe1b0f1f483 gtk_file_chooser_widget_init.lto_priv.0 (libgtk-3.so.0 + 0x11f483) #57 0x00007fe1c2f0a3a1 g_type_create_instance (libgobject-2.0.so.0 + 0x333a1) #58 0x00007fe1c2eef8a4 g_object_new_internal.part.0 (libgobject-2.0.so.0 + 0x188a4) #59 0x00007fe1c2ef1283 g_object_newv (libgobject-2.0.so.0 + 0x1a283) #60 0x00007fe1b0e536cc _gtk_builder_construct (libgtk-3.so.0 + 0x536cc) #61 0x00007fe1b0e53cff builder_construct (libgtk-3.so.0 + 0x53cff) #62 0x00007fe1b0e54b41 start_element (libgtk-3.so.0 + 0x54b41) #63 0x00007fe1c38ef9c9 emit_start_element (libglib-2.0.so.0 + 0x459c9) ```
Thanks for the update Martin. However, it might be noted: while the crashes with file managers are the ones that are 100% reproducible, the crash with the same outputs also occurs sometimes on websites (see my comment #8 including an example error report -> https://bugzilla.redhat.com/show_bug.cgi?id=2412225#c8 ). Shall I also move BZ#2403355 to gtk3? I am still not sure if it is the same issue, but at least the file manager/download issue occurs on both in the same way, and the header of the TB window is affected too.
(In reply to Christopher Klooz from comment #16) > Thanks for the update Martin. However, it might be noted: while the crashes > with file managers are the ones that are 100% reproducible, the crash with > the same outputs also occurs sometimes on websites (see my comment #8 > including an example error report -> > https://bugzilla.redhat.com/show_bug.cgi?id=2412225#c8 ). That's crash in local gtk3 library and may not be related to the crash above. Can you try to get the backtrace via coredumpctl? https://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Using_coredumpctl_to_get_backtrace (you also need to have installed debuginfo for local libraries). Thanks.
We tried that already, see my comment 7 -> https://bugzilla.redhat.com/show_bug.cgi?id=2412225#c7 coredumpctl does not document the crashes of Firefox at all, neither the file-manager-crashes nor those that occur on websites without downloads being involved. However, I just saw that the Thunderbird crashes are documented in coredumpctl, so the crashes that occur when I try to attach a file to an email, which I presume is the same issue as that in Firefox (the crash occurs the moment a file manager is to be opened, just like in Firefox). I upload the crash of thunderbird of the moment the file manager should have been opened (assuming the origin is the same as in Firefox when it crashes the moment a file manager is to be opened for downloads) with another browser in the next post: after getting the ID of the thunderbird crash, I started gdb with `coredumpctl debug 5222 |& tee backtrace.log` and then I did `thread apply all bt full` within gdb. All outputs are in the file I upload in the next post.
Created attachment 2116188 [details] coredumpctl debug 5222 |& tee backtrace.log
The following is primarily about BZ#2412225, but it finally distinguishes the difference between BZ#2412225 and BZ#2403355, so its related to both: For reasons I do not yet understand, one of the two issues is related to SELinux. I disabled the SELinux confinement (sysadm_u [with x enabled] -> unconfined_u of user account), rebooted to ensure ideal context of the boot, then logged in: Firefox could then properly download files with a file manager without a problem, and Thunderbird's performance issues then limited again to the calendar as before the upgrade (while the reminders still are not reliable, which was not the case before the upgrade to F43, but the issue decreased in intensity as "two reminders" survived [did not any one time work since upgrading] the night while another one did not). Once I enabled the confinement again (unconfined_u -> sysadm_u of user account), Firefox broke again with downloads the same way as reported in this bug report, and Thunderbird also had again the performance issues throughout its functions and in all emails (while the calendar & reminder issue seems to be something separate). The header of Thunderbird window (so with the three buttons for minimize,maximize,exit) was also working again without confinement, but broke again after re-enabling confinement. The reason why I never considered this is because the SELinux-denials did not change after the upgrade: it is still the denials that are known for long and ignored due to not causing issues. The first login after I enabled confinement again (so with sysadm_u) was at 10:59: all denials that are logged today occurred after I logged in WITH confinement: see for the setsetroubleshoot log [1]. As mentioned, these denials are not new but tolerated for several releases (I think they were already mentioned/evaluated in some tickets in semanage-policy back then). The other issue my system has since upgrading, and I mention it due to its potential relation to gtk: regular crashes/coredump of `maliit-keyboard`, while when I changed the virtual keyboard to the alternative `ibus-ui-gtk3`, the crashes/coredumps were still the same, but then accordingly with `ibus-ui-gtk3` -> I upload the "coredump-maliit.txt" (maliit-keyboard) and "coredump-ibus.txt" (ibus-ui-gtk3) separately with another browser in the next post -> as you see at the timestamps, these coredumps/crashes took place also when I was NOT on confinement (as it took place before 10:59, which means it was when I was initially logged in without confinement -> that boot did not contain any confinement at all) -> not sure if SELinux is maybe just provoking symptoms and is itself not the origin of the problem? I'd involve @zpytela to see if he has any idea of how these denials can be related to this impact (?) ------------------ATTACHMENT------------------ [1] output of `journalctl --boot=0 --unit setroubleshoot.service > filename` (the previous boot, -1, which did not involve confinement, did not log any denials) ``` Nov 27 10:59:15 fedora systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs... Nov 27 10:59:16 fedora systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs. Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing wireplumber from 'read, write' accesses on the chr_file media0. For complete SELinux messages run: sealert -l 090e15bd-fa04-4249-8135-28bd871930ea Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing wireplumber from 'read, write' accesses on the chr_file media0. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that wireplumber should be allowed read write access on the media0 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'wireplumber' --raw | audit2allow -M my-wireplumber # semodule -X 300 -i my-wireplumber.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing wireplumber from 'read, write' accesses on the chr_file media1. For complete SELinux messages run: sealert -l 090e15bd-fa04-4249-8135-28bd871930ea Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing wireplumber from 'read, write' accesses on the chr_file media1. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that wireplumber should be allowed read write access on the media1 chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'wireplumber' --raw | audit2allow -M my-wireplumber # semodule -X 300 -i my-wireplumber.pp Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing Chrome_InProcGp from 'read, write' accesses on the chr_file udmabuf. For complete SELinux messages run: sealert -l 21204e92-6e16-4ff1-ba7b-7745fddcbefc Nov 27 10:59:19 fedora setroubleshoot[3080]: SELinux is preventing Chrome_InProcGp from 'read, write' accesses on the chr_file udmabuf. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that Chrome_InProcGp should be allowed read write access on the udmabuf chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'Chrome_InProcGp' --raw | audit2allow -M my-ChromeInProcGp # semodule -X 300 -i my-ChromeInProcGp.pp Nov 27 10:59:29 fedora systemd[1]: setroubleshootd.service: Deactivated successfully. Nov 27 10:59:29 fedora systemd[1]: setroubleshootd.service: Consumed 2.329s CPU time, 84.4M memory peak. Nov 27 10:59:32 fedora systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs... Nov 27 10:59:33 fedora systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs. Nov 27 10:59:35 fedora setroubleshoot[4224]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 10:59:35 fedora setroubleshoot[4224]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 10:59:46 fedora systemd[1]: setroubleshootd.service: Deactivated successfully. Nov 27 10:59:46 fedora systemd[1]: setroubleshootd.service: Consumed 1.745s CPU time, 67M memory peak. Nov 27 11:07:06 fedora systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs... Nov 27 11:07:06 fedora systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs. Nov 27 11:07:08 fedora setroubleshoot[11107]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 11:07:08 fedora setroubleshoot[11107]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 11:07:18 fedora systemd[1]: setroubleshootd.service: Deactivated successfully. Nov 27 11:07:18 fedora systemd[1]: setroubleshootd.service: Consumed 1.090s CPU time, 67.4M memory peak. Nov 27 11:07:33 fedora systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs... Nov 27 11:07:33 fedora systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs. Nov 27 11:07:36 fedora setroubleshoot[11842]: SELinux is preventing rtkit-daemon from using the setsched access on a process. For complete SELinux messages run: sealert -l ce564713-6cde-478e-9285-84606429d90c Nov 27 11:07:36 fedora setroubleshoot[11842]: SELinux is preventing rtkit-daemon from using the setsched access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rtkit-daemon should be allowed setsched access on processes labeled sysadm_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rtkit-daemon' --raw | audit2allow -M my-rtkitdaemon # semodule -X 300 -i my-rtkitdaemon.pp Nov 27 11:07:46 fedora systemd[1]: setroubleshootd.service: Deactivated successfully. Nov 27 11:07:46 fedora systemd[1]: setroubleshootd.service: Consumed 1.794s CPU time, 67.1M memory peak. ```
Created attachment 2116336 [details] coredump-maliit.txt See Comment 20
Created attachment 2116337 [details] coredump-ibus.txt See Comment 20
Christopher, Can you try the following policy module? # cat local_sysadm.cil (allow rtkit_daemon_t sysadm_t (process (setsched))) (allow sysadm_t dma_device_t (chr_file (getattr ioctl open read write))) (allow sysadm_t self (netlink_route_socket (nlmsg_write))) (allow sysadm_t fs_t (filesystem (remount unmount))) (allow sysadm_t init_t (unix_stream_socket (read write))) (allow sysadm_t xdm_t (unix_stream_socket (read write))) # semodule -i local_sysadm.cil
> # cat local_sysadm.cil > (allow rtkit_daemon_t sysadm_t (process (setsched))) > (allow sysadm_t dma_device_t (chr_file (getattr ioctl open read write))) > (allow sysadm_t self (netlink_route_socket (nlmsg_write))) > (allow sysadm_t fs_t (filesystem (remount unmount))) > (allow sysadm_t init_t (unix_stream_socket (read write))) > (allow sysadm_t xdm_t (unix_stream_socket (read write))) > > # semodule -i local_sysadm.cil Done! BZ#2412225 solved! I can download again in Firefox, attach files in Thunderbird, and while BZ#2403355 remains *¹ , the other Thunderbird performance issues + broken window header are solved as well! Does it make sense to deploy this policy change systemwide to re-enable sysadm_u? (for many with confinement, sysadm_u is the only useful profile due to the limitations of staff_u). I also ask concerning closing this as fixed now or waiting until we can close it with ERRATA. I would then leave BZ#2403355 open but update it later with the remaining issue *¹ (which seems not related to SELinux). Thanks Zdenek & Martin for your support :)) ---------- *¹ slow calendar processing with occasional freezes when calendar is involved; unreliable reminders not yet tested but can be predicted to remain broken given that unconfined_u did not impact the calendar-related phenomenons
Switching the component. You can # semodule -r local_sysadm once the changes get into policy. > Does it make sense to deploy this policy change systemwide to re-enable > sysadm_u? (for many with confinement, sysadm_u is the only useful profile > due to the limitations of staff_u). I also ask concerning closing this as > fixed now or waiting until we can close it with ERRATA. yes, sysadm_u user is supported, although the recommended way is to log in as staff_u and then change roles when needed. new Fedora actually needs some adjustments also for staff_u
FEDORA-2026-12f4b22ac5 (selinux-policy-43.6-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-12f4b22ac5
FEDORA-2026-12f4b22ac5 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-12f4b22ac5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-12f4b22ac5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thanks! Issue solved. I did `semodule -r local_sysadm` and then tested if the issue is still there: it is. Then I updated to `selinux-policy-43.6-1.fc43` and tested again: issue gone :) I reported in bodhi and close here with errata.
FEDORA-2026-12f4b22ac5 (selinux-policy-43.6-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.