Trying to get good stack trace from the crash. But "coredumpctl gdb <processID>" gives me, "No match found."

Ask Fedora
1

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 coredumpctl command.

pranav@fedora ~> journalctl -b | rg -B3 -A5 -i 'glib'
Sep 15 09:37:53 fedora ibus-daemon[1338]: 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][883]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Sep 15 09:37:53 fedora audit[883]: 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[883]: 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][883]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Sep 15 09:37:53 fedora gsd-color[1825]: 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[827]: Session c1 logged out. Waiting for processes to exit.

Since it said, gdm-launch-environment [883], 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:

  1. Why my core files are missing in the first place?
  2. 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.
  1. 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?
  2. Is coredumpctl affected by the journalctl storage limit? If not, then we can totally ignore question 3rd question.
  3. journalctl --verify gives 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.

1 Like
2

Do you have abrt installed, have you looked to see if it has generated all of this for you?

I don’t think this is related to the corrupt journal entries—coredumps should be stored independently as far as I know, but I think they’re also cleaned up from time to time.

if you have abrt installed, that’ll (should) process coredumps by default.

Here are some links to look at:

https://fedoraproject.org/wiki/StackTraces

PS: I see that you filed a topic on the Gnome discourse instance too, so it’s probably best to keep following up there. Too many discussions will give you far too many responses/ideas and that just makes it harder to follow

3

Do you have abrt installed,

Abrt is already installed. It was installed long time ago.
Package abrt-2.14.6-3.fc34.x86_64 is already installed.

have you looked to see if it has generated all of this for you?

Well, it says no problem so far.

pranav@fedora ~> abrt list
No problems

I think they’re also cleaned up from time to time.

Maybe we need to stop this “leave no trace behind” behavior. Why aren’t coredumps being recorded or stored?!

I see that you filed a topic on the Gnome discourse instance too, so it’s probably best to keep following up there. Too many discussions will give you far too many responses/ideas and that just makes it harder to follow

Yesterday I reported that issue and created a post there during the night and slept. After my first replay today, it has been already 6 hours, there is no response so far. I don’t want the issue to be dead until I get my coredumps for report.

4

I didn’t say they’re not being stored. i said they’re being removed after some time. :slight_smile:

I think you need to be a little more patient. First, we’re all in different time zones—you being awake does not mean the world is awake. Next, remember that all of us are volunteers, so we also have jobs and personal lives that need our time. Folks reply when they can, and in your case lots of folks are replying both to the bug and to your discussions. So please, if you’re relying on others for help, be patient :slight_smile:

PS: the simplest way to debug this is to see if you can reproduce it in a fresh installation, where you know for sure that you haven’t modified any system settings. If you can do that in a virtual machine, that’ll be a great help to the devs.

5

Okay, I’ll wait. Hope someone will come up with something.

1 Like
6

If you look at man coredump.conf, it has some settings on modifying the configuration of coredumpctl. Worth a look. For example, maybe change Storage to external and see how that goes?

(Had edited my post but realised you probably wouldn’t get notified for that)

1 Like