Process 8364 (gnome-session-i) of user 1000 dumped core.
Module /usr/libexec/gnome-session-init-worker from rpm gnome-session-50.0-1.fc44.x86_64
Module libbrotlicommon.so.1 from rpm brotli-1.2.0-3.fc44.x86_64
Module libgraphite2.so.3 from rpm graphite2-1.3.14-20.fc44.x86_64
Module libbrotlidec.so.1 from rpm brotli-1.2.0-3.fc44.x86_64
Module libharfbuzz.so.0 from rpm harfbuzz-12.3.2-1.fc44.x86_64
Module libpng16.so.16 from rpm libpng-1.6.55-1.fc44.x86_64
Module libbz2.so.1 from rpm bzip2-1.0.8-23.fc44.x86_64
Module libfreetype.so.6 from rpm freetype-2.14.1-2.fc44.x86_64
Module liblzma.so.5 from rpm xz-5.8.2-2.fc44.x86_64
Module libfontconfig.so.1 from rpm fontconfig-2.17.0-4.fc44.x86_64
Module liblcms2.so.2 from rpm lcms2-2.16-7.fc44.x86_64
Module libxml2.so.2 from rpm libxml2-2.12.10-6.fc44.x86_64
Module libglycin-2.so.0 from rpm glycin-2.1.0-1.fc44.x86_64
Module libblkid.so.1 from rpm util-linux-2.41.3-12.fc44.x86_64
Module libseccomp.so.2 from rpm libseccomp-2.6.0-3.fc44.x86_64
Module libudev.so.1 from rpm systemd-259.5-1.fc44.x86_64
Module libxkbregistry.so.0 from rpm libxkbcommon-1.13.1-2.fc44.x86_64
Module libsystemd.so.0 from rpm systemd-259.5-1.fc44.x86_64
Module libgdk_pixbuf-2.0.so.0 from rpm gdk-pixbuf2-2.44.4-2.fc44.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.47-1.fc44.1.x86_64
Module libffi.so.8 from rpm libffi-3.5.2-2.fc44.x86_64
Module libselinux.so.1 from rpm libselinux-3.10-1.fc44.x86_64
Module libmount.so.1 from rpm util-linux-2.41.3-12.fc44.x86_64
Module libz.so.1 from rpm zlib-ng-2.3.3-3.fc44.x86_64
Module libgmodule-2.0.so.0 from rpm glib2-2.88.0-1.fc44.x86_64
Module libgnome-desktop-4.so.2 from rpm gnome-desktop3-44.5-1.fc44.x86_64
Module libglib-2.0.so.0 from rpm glib2-2.88.0-1.fc44.x86_64
Module libgobject-2.0.so.0 from rpm glib2-2.88.0-1.fc44.x86_64
Module libgio-2.0.so.0 from rpm glib2-2.88.0-1.fc44.x86_64
Stack trace of thread 8364:
#0 0x00007fcad896a9ac __pthread_kill_implementation (libc.so.6 + 0x759ac)
#1 0x00007fcad890f34e raise (libc.so.6 + 0x1a34e)
#2 0x00007fcad88f67b3 abort (libc.so.6 + 0x17b3)
#3 0x00007fcad8b41471 _g_log_abort.lto_priv.0.cold (libglib-2.0.so.0 + 0x2471)
#4 0x00007fcad8b8df60 g_log_default_handler (libglib-2.0.so.0 + 0x4ef60)
#5 0x00007fcad8b8e283 g_logv (libglib-2.0.so.0 + 0x4f283)
#6 0x00007fcad8b8e5e3 g_log (libglib-2.0.so.0 + 0x4f5e3)
#7 0x000055ecf96281ca main (/usr/libexec/gnome-session-init-worker + 0x11ca)
#8 0x00007fcad88f8681 __libc_start_call_main (libc.so.6 + 0x3681)
#9 0x00007fcad88f8798 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3798)
#10 0x000055ecf9628575 _start (/usr/libexec/gnome-session-init-worker + 0x1575)
Stack trace of thread 8399:
#0 0x00007fcad89ea99d syscall (libc.so.6 + 0xf599d)
#1 0x00007fcad8bb722b g_cond_wait (libglib-2.0.so.0 + 0x7822b)
#2 0x00007fcad8b4958c g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0xa58c)
#3 0x00007fcad8bbdaa4 g_thread_pool_spawn_thread (libglib-2.0.so.0 + 0x7eaa4)
#4 0x00007fcad8bbca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#5 0x00007fcad89688f9 start_thread (libc.so.6 + 0x738f9)
#6 0x00007fcad89ecc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 8401:
#0 0x00007fcad8970fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007fcad896520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007fcad8965254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007fcad89dfaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007fcad8b87065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007fcad8b87227 g_main_loop_run (libglib-2.0.so.0 + 0x48227)
#6 0x00007fcad8df96c2 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0xf76c2)
#7 0x00007fcad8bbca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007fcad89688f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007fcad89ecc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 8400:
#0 0x00007fcad8970fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007fcad896520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007fcad8965254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007fcad89dfaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007fcad8b87065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007fcad8b87123 g_main_context_iteration (libglib-2.0.so.0 + 0x48123)
#6 0x00007fcad8b87171 glib_worker_main (libglib-2.0.so.0 + 0x48171)
#7 0x00007fcad8bbca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007fcad89688f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007fcad89ecc0c __clone3 (libc.so.6 + 0xf7c0c)
ELF object binary architecture: AMD x86-64
Please raise a bug report about this - Making sure you're not a bot!
Also include info about your system from inxi -Fzxx as this may be hardware related.
Did you manage to solve this? Same here with latest updates as if today.
I have the same crash on Fedora 44 with gnome-session-50.0-1.fc44.x86_64. Identical stack trace, same offset +0x11ca in main().
I did a fresh install of Fedora 43 a few months ago and triggered an update to Fedora 44 via the UI on 30.05 . Result is: My existing user cannot log in to Gnome, but to tty. A newly create user can login to Gnome.
After some debugging with the help of Claude I can add the following findings:
- The crash is profile-specific — a newly created test user logs in fine
- PAM authentication succeeds, the session opens, then
gnome-session-init-workeraborts with SIGABRT ~3 seconds later - Ruled out: extensions, dconf,
~/.config/gnome-shell, AccountsService (no malcontent section),recently-used.xbel(valid XML), fulldnf upgrade /var/lib/AccountsService/users/<user>is clean- The abort happens via
g_assertion_message_expr.cold()inmain()— something in the existing user profile triggers a GLib assertion that a fresh profile does not
Workaround for now: logging in as a different user works. Waiting for an upstream fix.
I hope someone reported this in the fedora or gnome bugtracker, otherwise I fear no one knows that a fix is required to be made.
I hope I I am not the first experiencing this issue. So well then: If this is bug tracker worthy, then I work my way through the bug tracker.
Thanks for bringing this up
Hi,
This is an interesting one — and the details shared by holgergp help a lot.
From what I understand so far:
- the crash happens in gnome-session-init-worker (with a GLib abort)
- a fresh user logs in fine
- the existing user consistently crashes
- common things like extensions, dconf, and basic config have already been checked
To me, this doesn’t look like a system-wide or hardware issue.
The fact that a new user works is a strong hint that this is something tied to the user profile. Also, since the crash is triggered by GLib (g_log → abort), it’s probably an internal check failing rather than a random crash.
My guess would be that something in the existing profile is no longer tolerated by the newer GNOME stack in Fedora 44. Even if the usual suspects (~/.config, dconf, etc.) look fine, there are still a few less obvious places that can affect session startup.
A couple of things that might be worth trying (if not already done):
-
Clear some session-related cache:
rm -rf ~/.local/share/gnome-shell
rm -rf ~/.cache/* -
Try launching a very clean session from TTY:
env -i startx(just to rule out environment-related issues)
-
Check if any user services look odd:
systemctl --user list-units -
Compare environment variables between the working and broken user:
env | sort
As a more “last resort” kind of test, you could also try:
dconf reset -f /
(just to see if it makes a difference — it will reset your preferences)
At this point, it really feels like a profile-triggered issue rather than a general GNOME failure.
Since more than one person is seeing the same pattern (fresh user OK, existing user not), this might well be a regression or a stricter check introduced in newer GNOME components.
Using a new user is a reasonable workaround for now, but it would be interesting to find exactly what in the profile is causing this.
Curious if anyone manages to pinpoint it.
Regards
G/T
I would appreciate if someone with more Bugzilla and Fedora tenure could have a look at this BugReport and help me improve it.
Thanks!
Re,
Your report is already quite solid — especially the stack trace and the fact that a new user can log in fine, that’s actually a really important clue 
If I may suggest a couple of small improvements that might help maintainers more quickly understand and act on it: I’d make that “existing user fails but new user works” point very visible right at the top, since it strongly suggests this is something specific to the user profile rather than a system-wide issue. Maybe also add a short, simple reproduction summary (upgrade from Fedora 43 → 44, login fails for existing user, works for new one), just so it’s immediately clear what triggers it.
One thing that could really help narrow it down (if you haven’t already tried) would be to temporarily move ~/.config and ~/.cache out of the way or run dconf reset -f / — if GNOME starts after that, it would confirm that some user configuration is causing the crash, which is quite common after major GNOME upgrades.
Also, since the crash happens in gnome-session, it might be worth opening an issue upstream with GNOME and linking it back to your Bugzilla report — that usually helps get more visibility from the right maintainers.
Overall though, this is already a very useful report — reproducible, scoped, and with good technical detail — so you’re definitely on the right track 
Regards,
G/T
I first solved it by deleting a bunch of folders so dont know which caused it.
But i lost all my gnome settings and what not..
Two weeks later I rebooted again and same issue. So not sure if its any of my extensions something I do that triggers this.
Thanks for reporting Holger.
Re,
That’s actually a really useful data point.
The fact that deleting some folders fixed it once (even if temporarily) strongly suggests this is indeed something in the user profile getting into a bad state — not a system-wide issue.
The tricky part is that doing a “full reset” (like removing a bunch of folders) works, but as you saw, you lose all your settings and it doesn’t prevent it from happening again.
Given that it came back after a reboot, I’d start suspecting something that gets reloaded each session, like:
- a GNOME extension (even if it seems disabled)
- or some setting written back into dconf at login
If you want a less destructive approach next time, you could try:
- disabling all extensions at once (
gnome-extensions disable --all) - or resetting only GNOME-related settings with:
dconf reset -f /org/gnome/
That way you avoid wiping everything and might narrow it down a bit more.
At this point it really looks like a specific config or extension triggering a crash in the session init, especially after the upgrade.
If you happen to reproduce it again, it could be interesting to check logs right after a failed login from TTY:
journalctl -b | grep -E "gnome-session|gnome-shell"
That might give a hint about what gets loaded right before the crash.
Regards,
G/T
I tried moving ~/.cache and ~/.config. Sadly no luck
Regarding extensions (which I have disabled) I have installed dash-to-dock@micxgx.gmail.com and appindicatorsupport@gcjonas.gmail.com
Both do not seem to have documented issues with Gnome 50.
Is it safe/non destructive to do a dconf reset ... ?
And this is the ticket on the Gnome Gitlab:
Also here: I would appreciate if someone could look over this ticket. Right subproject? Missing tags? Anything else missing?
I’ve been having a similar issue with this for weeks when I was testing Fedora 44 Beta. Today, I sat down for a night to do a bit more testing
- I spun up a QEMU VM with virt-manager and did a clean install of F44 Workstation 3 times in a row until this gdm crash triggered
- This affected parent VM installed sucessfully, completed gnome-intial-setup, and was then rebooted. This subsequent login immediately crashed and the VM was booted back to gdm. Assuming this is the same bug
- The affected VM was shutdown and then used as a template for 4 clone VMs
| Reboot | Clone #1 | Clone #2 | Clone #3 | Clone #4 |
|---|---|---|---|---|
| #2 | works | x | x | x |
| #3 | tty-mode | x | x | x |
| #4 | x | tty-mode | works | x |
| #5 | works | works | works | x |
| #6 | x | works | works | works |
| #7 | x | x | x | tty-mode |
| #8 | x | x | works | tty-mode |
| #9 | works | x | works | x |
| #10 | x | works | tty-mode | x |
| #11 | x | x | tty-mode | x |
| #12 | x | works | x | works |
- works = can login without crashing
- x = login crashes and coredumps immediately
- tty-mode = gdm doesn’t load
Here’s a screenshot of Reboot #10 if the table wasn’t clear
And heres the stacktrace from a gdm login crash from Clone #2 on Reboot 12
May 05 21:35:27 fedora systemd-coredump[2427]: Process 2372 (gnome-shell) of user 1000 dumped core.
...
Stack trace of thread 2372:
#0 0x00007ffb9707a9ac __pthread_kill_implementation (libc.so.6 + 0x759ac)
#1 0x00007ffb9701f34e raise (libc.so.6 + 0x1a34e)
#2 0x000055ed40a6feb7 dump_gjs_stack_on_signal_handler (/usr/bin/gnome-shell + 0x1eb7)
#3 0x00007ffb9701f470 __restore_rt (libc.so.6 + 0x1a470)
#4 0x00007ffb9707a9ac __pthread_kill_implementation (libc.so.6 + 0x759ac)
#5 0x00007ffb9701f34e raise (libc.so.6 + 0x1a34e)
#6 0x00007ffb970067b3 abort (libc.so.6 + 0x17b3)
#7 0x00007ffb97851471 _g_log_abort.lto_priv.0.cold (libglib-2.0.so.0 + 0x2471)
#8 0x00007ffb9789df60 g_log_default_handler (libglib-2.0.so.0 + 0x4ef60)
#9 0x00007ffb9789e283 g_logv (libglib-2.0.so.0 + 0x4f283)
#10 0x00007ffb9789e5e3 g_log (libglib-2.0.so.0 + 0x4f5e3)
#11 0x00007ffb972b500f meta_context_start (libmutter-18.so.0 + 0xb500f)
#12 0x000055ed40a6f2d8 main (/usr/bin/gnome-shell + 0x12d8)
#13 0x00007ffb97008681 __libc_start_call_main (libc.so.6 + 0x3681)
#14 0x00007ffb97008798 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3798)
#15 0x000055ed40a6f6f5 _start (/usr/bin/gnome-shell + 0x16f5)
Stack trace of thread 2387:
#0 0x00007ffb970fa99d syscall (libc.so.6 + 0xf599d)
#1 0x00007ffb978c722b g_cond_wait (libglib-2.0.so.0 + 0x7822b)
#2 0x00007ffb9785958c g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0xa58c)
#3 0x00007ffb978cdaa4 g_thread_pool_spawn_thread (libglib-2.0.so.0 + 0x7eaa4)
#4 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#5 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#6 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2397:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075557 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x70557)
#3 0x00007ffb97077dac pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x72dac)
#4 0x00007ffb94f5c79e _ZN2js12HelperThread10ThreadMainEPNS_18InternalThreadPoolEPS0_ (libmozjs-140.so.0 + 0x15c79e)
#5 0x00007ffb94f69571 _ZN2js6detail16ThreadTrampolineIRFvPNS_18InternalThreadPoolEPNS_12HelperThreadEEJRS3_S5_EE5StartEPv (libmozjs-140.so.0 + 0x169571)
#6 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#7 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2388:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007ffb970efaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007ffb97897065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007ffb97897123 g_main_context_iteration (libglib-2.0.so.0 + 0x48123)
#6 0x00007ffb97897171 glib_worker_main (libglib-2.0.so.0 + 0x48171)
#7 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2389:
#0 0x00007ffb970fa99d syscall (libc.so.6 + 0xf599d)
#1 0x00007ffb978c81e9 g_cond_wait_until (libglib-2.0.so.0 + 0x791e9)
#2 0x00007ffb9785954d g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0xa54d)
#3 0x00007ffb978ce852 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7f852)
#4 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#5 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#6 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2393:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007ffb970efaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007ffb97897065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007ffb97897123 g_main_context_iteration (libglib-2.0.so.0 + 0x48123)
#6 0x00007ffb97edb11d dconf_gdbus_worker_thread (libdconfsettings.so + 0x511d)
#7 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2390:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007ffb970efaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007ffb97897065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007ffb97897227 g_main_loop_run (libglib-2.0.so.0 + 0x48227)
#6 0x00007ffb97b096c2 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0xf76c2)
#7 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2394:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075557 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x70557)
#3 0x00007ffb97077dac pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x72dac)
#4 0x00007ffb94f5c79e _ZN2js12HelperThread10ThreadMainEPNS_18InternalThreadPoolEPS0_ (libmozjs-140.so.0 + 0x15c79e)
#5 0x00007ffb94f69571 _ZN2js6detail16ThreadTrampolineIRFvPNS_18InternalThreadPoolEPNS_12HelperThreadEEJRS3_S5_EE5StartEPv (libmozjs-140.so.0 + 0x169571)
#6 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#7 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2395:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075557 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x70557)
#3 0x00007ffb97077dac pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x72dac)
#4 0x00007ffb94f5c79e _ZN2js12HelperThread10ThreadMainEPNS_18InternalThreadPoolEPS0_ (libmozjs-140.so.0 + 0x15c79e)
#5 0x00007ffb94f69571 _ZN2js6detail16ThreadTrampolineIRFvPNS_18InternalThreadPoolEPNS_12HelperThreadEEJRS3_S5_EE5StartEPv (libmozjs-140.so.0 + 0x169571)
#6 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#7 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2396:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075557 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x70557)
#3 0x00007ffb97077dac pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x72dac)
#4 0x00007ffb94f5c79e _ZN2js12HelperThread10ThreadMainEPNS_18InternalThreadPoolEPS0_ (libmozjs-140.so.0 + 0x15c79e)
#5 0x00007ffb94f69571 _ZN2js6detail16ThreadTrampolineIRFvPNS_18InternalThreadPoolEPNS_12HelperThreadEEJRS3_S5_EE5StartEPv (libmozjs-140.so.0 + 0x169571)
#6 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#7 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2415:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007ffb970efaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007ffb97897065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007ffb97897227 g_main_loop_run (libglib-2.0.so.0 + 0x48227)
#6 0x00007ffb973a2ac9 input_thread (libmutter-18.so.0 + 0x1a2ac9)
#7 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2410:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075254 __syscall_cancel (libc.so.6 + 0x70254)
#3 0x00007ffb970efaa6 ppoll (libc.so.6 + 0xeaaa6)
#4 0x00007ffb97897065 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x48065)
#5 0x00007ffb97897227 g_main_loop_run (libglib-2.0.so.0 + 0x48227)
#6 0x00007ffb973ac2d6 thread_impl_func (libmutter-18.so.0 + 0x1ac2d6)
#7 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#8 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#9 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2414:
#0 0x00007ffb97080fd2 __syscall_cancel_arch (libc.so.6 + 0x7bfd2)
#1 0x00007ffb9707520c __internal_syscall_cancel (libc.so.6 + 0x7020c)
#2 0x00007ffb97075557 __GI___futex_abstimed_wait_cancelable64 (libc.so.6 + 0x70557)
#3 0x00007ffb97077dac pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x72dac)
#4 0x00007ffb6c80028d cnd_wait (libgallium-26.0.3.so + 0x60028d)
#5 0x00007ffb6c7b602c util_queue_thread_func (libgallium-26.0.3.so + 0x5b602c)
#6 0x00007ffb6c8001cc impl_thrd_routine (libgallium-26.0.3.so + 0x6001cc)
#7 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#8 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
Stack trace of thread 2417:
#0 0x00007ffb970fa99d syscall (libc.so.6 + 0xf599d)
#1 0x00007ffb978c81e9 g_cond_wait_until (libglib-2.0.so.0 + 0x791e9)
#2 0x00007ffb9785954d g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0xa54d)
#3 0x00007ffb978ce852 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7f852)
#4 0x00007ffb978cca52 g_thread_proxy (libglib-2.0.so.0 + 0x7da52)
#5 0x00007ffb970788f9 start_thread (libc.so.6 + 0x738f9)
#6 0x00007ffb970fcc0c __clone3 (libc.so.6 + 0xf7c0c)
ELF object binary architecture: AMD x86-64
May 05 21:35:27 fedora systemd[1]: systemd-coredump@0-1-2426_2427-0.service: Deactivated successfully.
I tested a couple more times after updating each CLone VM latest F44, which included updates to GNOME 50.1
| Reboot | Clone #1 | Clone #2 | Clone #3 | Clone #4 |
|---|---|---|---|---|
| #14 | works | works | works | works |
| #15 | works | x | x | works |
| #16 | tty-mode | works | x | works |
| #17 | works | works | works | x |
| #18 | x | works | x | works |
| #19 | works | x | x | x |
| #20 | x | x | works | works |
Hi, I don’t know if this will help you, but hopefully it will.
I had the exact same issue and stack trace. But, in journalctl, I noticed that I was getting the following line right before the crash:
fedora gnome-session-i[2463]: Failed to start unit gnome-session@gnome-login.target:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied:
SELinux policy denies access: Permission denied
At this point it was clear that SELinux was preventing GNOME from creating a session. So what I did was change SELinux to permissive (in /etc/selinux/config) and added a file named .autorelabel in root to trigger relabling.
This worked. Keep in mind I switched kernel to 43 via GRUB before trying this. Before the fix, even trying to boot into 43 did not work. I will let you know if it boots with 44.
I don’t know if this is the same reason your GNOME crashed, but if it is, I hope it helps!
The issue started after I attempted to switch the desktop session from standard GNOME to GNOME Classic. After making the change, Fedora began crashing at the login stage.
I ran into the similar issue today with the g_assertion_message_expr.cold() assertion.
After a day of troubleshooting, I traced the problem to the autostart script generated by Zellij.
For context, I’m using the Zellij tarball, not the DNF package.
There’s an existing issue in the Zellij repository that matches this:
Interestingly, the person who opened the issue is on Fedora KDE - not GNOME.
I just saw this
Thanks for the headsup.
I just updated the Fedora ticket with the status from the Gnome ticket.