Problem: GLib-GObject: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed
Someone report this bug. The reporter doesn’t seem to see this issue in his distro (Fedora 34) anymore. But I still do in my Fedora 34 happening every time whenever power on the OS. Very reproducable. Since this bug report lacked important logs, I wanted to pitch in and give them what might be helpful in solving this issue.
So after reading their discussion, I installed different debugging packages using this command:
sudo dnf debuginfo-install gdm glic2
Read the journctl output to get the PID so that I can use it later in
pranav@fedora ~> journalctl -b | rg -B3 -A5 -i 'glib' Sep 15 09:37:53 fedora ibus-daemon: GChildWatchSource: Exit status of a child process was requested but ECHILD was received by waitpid(). See the documentation of g_child_watch_source_new() for possible causes. Sep 15 09:37:53 fedora gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session closed for user gdm Sep 15 09:37:53 fedora audit: USER_END pid=883 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_close grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=fedora addr=? terminal=/dev/tty1 res=success' Sep 15 09:37:53 fedora audit: CRED_DISP pid=883 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_permit acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=fedora addr=? terminal=/dev/tty1 res=success' Sep 15 09:37:53 fedora gdm-launch-environment]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Sep 15 09:37:53 fedora gsd-color: failed to connect to device: Failed to connect to missing device /org/freedesktop/ColorManager/devices/xrandr_AU_Optronics_gdm_42 Sep 15 09:37:53 fedora systemd-logind: Session c1 logged out. Waiting for processes to exit.
Since it said,
gdm-launch-environment , I did this:
pranav@fedora ~> coredumpctl gdb 883 No match found.
At this point, I think I have annoyed Gnome Triage named Andre because I was polluting this GitHub issue with back-and-forth questions about, “why I’m not getting the logs, how to get the logs”. He recommended me to go here and ask. And I did. The last thing he said was, "Your corefiles are missing above. So there’s no data to look at. "
These are my coredump files:
pranav@fedora ~> sudo coredumpctl list [sudo] password for pranav: TIME PID UID GID SIG COREFILE EXE SIZE Tue 2021-08-03 16:37:54 +0545 24968 1000 1000 SIGSEGV missing /usr/bin/mono-sgen n/a Wed 2021-08-11 11:30:06 +0545 3173 1000 1000 SIGSEGV missing /usr/bin/gnome-shell n/a Tue 2021-08-24 13:17:16 +0545 16542 1000 1000 SIGTRAP missing /tmp/.mount_FreezesFSzqL/freezer n/a Thu 2021-09-02 17:04:28 +0545 2977 1000 1000 SIGSEGV missing /usr/bin/gnome-logs n/a Thu 2021-09-02 17:06:39 +0545 2506 1000 1000 SIGSEGV missing /usr/bin/gnome-logs n/a Thu 2021-09-02 21:26:36 +0545 5616 1000 1000 SIGSEGV missing /app/bin/cherrytree n/a Fri 2021-09-03 21:24:24 +0545 3431 1000 1000 SIGSEGV missing /usr/bin/gnome-logs n/a Sun 2021-09-05 20:37:39 +0545 6231 1000 1000 SIGSEGV missing /usr/bin/gnome-logs n/a Sun 2021-09-05 21:46:35 +0545 2403 1000 1000 SIGSEGV missing /usr/bin/gnome-logs n/a Sun 2021-09-12 06:09:07 +0545 3509 1000 1000 SIGABRT missing /app/bin/telegram-desktop n/a Sun 2021-09-12 11:05:54 +0545 1613 1000 1000 SIGSEGV missing /usr/bin/gnome-shell n/a pranav@fedora ~>
So my question for you is:
- Why my core files are missing in the first place?
- How do I enable (or bring back) my core files so that I can use coredumpctl command to get the log?
pranav@fedora ~> ulimit -c unlimited
As you can see there is no custom limit. But I do think I’ve set a limit in journalctl logs long time ago.
pranav@fedora ~> journalctl --disk-usage Archived and active journals take up 696.0M in the file system.
- Is there a similar verify command to be sure whether I have a limit in journalctl logs or not, and how much is that limit?
- Is coredumpctl affected by the journalctl storage limit? If not, then we can totally ignore question 3rd question.
journalctl --verifygives me a lot of red lines which start with warnings like, “File corruption detected at …” as you can see here. Is it normal? or does it need some fixes too?! I think this is the main cause of the problem which is my we can’t see any logs listed in coredumpctl. But I can be wrong.
Any help/tips is much appreciated.