Looking for help debugging and reporting a bug

Desktop
, ,
1

Dear all,
Ever since I had to replace my stolen T440s with a slightly newer T450s on which I am running Fedora (first F34, now F35), I am experiencing a really annoying bug: After opening the lid of my notebook, waking up from standby, the GDM log in screen is frozen and I have to wait a minute until something in the background crashes, restarts and GDM let’s me log in again.

I tried to report the bug as an issue on Gitlab: gdm seems to crash after standby: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (#730) · Issues · GNOME / gdm · GitLab
However, I don’t have the knowledge to produce a comprehensive bug report that includes a stack trace with debug symbols and whatever else is needed to analyze what’s going wrong here.

So, I described the symptoms, let’s repeat what the log message says:

22:10:48 gdm-session-wor: GLib-GObject: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed

What else I have done in preparation…

sudo dnf debuginfo-install gdm glib2

journalctl -b | rg -B3 -A5 -i 'glib' shows:

Jan 27 22:10:48 fedora gdm-launch-environment][1601]: GLib-GObject: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed
`

One of my problems is that I can’t find a coredump for this event coredumpctl gdb 1601

No match found.

Second try after rebooting, journalctl -b | rg -B3 -A5 -i 'glib' shows

Jan 27 23:46:17 fedora gdm-launch-environment][1415]: GLib-GObject: g_object_unref: assertion ‘G_IS_OBJECT (object)’ failed

But coredumpctl gdb 1415 says: No match found.

How do I overcome this?
What would be the next step?
What else may I provide?
How do I perform what @mcatanzaro suggested in gdm seems to crash after standby: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (#730) · Issues · GNOME / gdm · GitLab?

G_DEBUG=fatal-criticals` in your environment

?

Here is an excerpt of my coredumpctl list 

TIME                           PID  UID  GID SIG     COREFILE     EXE                                              SIZE
Tue 2021-08-17 22:45:37 CEST  2186 1000 1000 SIGSEGV missing      /usr/bin/gnome-shell                              n/a
Mon 2021-09-13 23:10:27 CEST  2106 1000 1000 SIGSEGV missing      /usr/bin/gnome-shell                              n/a
Tue 2021-09-14 00:00:34 CEST  3286   42   42 SIGABRT missing      /usr/bin/Xwayland                                 n/a
Tue 2021-09-14 00:37:24 CEST  2054 1000 1000 SIGSEGV missing      /usr/bin/gnome-shell                              n/a
Tue 2021-09-14 20:53:10 CEST  2625 1000 1000 SIGSEGV missing      /usr/bin/gnome-shell                              n/a
Mon 2021-09-20 23:26:05 CEST  3346 1000 1000 SIGSEGV missing      /usr/bin/gnome-shell                              n/a
Fri 2021-10-15 14:39:00 CEST 28458 1000 1000 SIGABRT missing      /usr/bin/nautilus                                 n/a
Tue 2021-11-02 23:48:40 CET  21052 1000 1000 SIGSEGV missing      /usr/bin/nautilus                                 n/a
Sun 2021-11-07 00:17:36 CET   6927 1000 1000 SIGSEGV missing      /usr/bin/nautilus                                 n/a
Wed 2021-11-24 20:19:09 CET   4319 1000 1000 SIGABRT missing      /usr/bin/gnome-control-center                     n/a
Wed 2021-11-24 23:42:00 CET   2983 1000 1000 SIGABRT missing      /usr/bin/gnome-software             
Mon 2021-11-29 22:02:13 CET   2718 1000 1000 SIGABRT missing      /usr/bin/gnome-shell                              n/a
Mon 2021-11-29 22:02:15 CET  47632 1000 1000 SIGSEGV missing      /app/discord/Discord                              n/a
Fri 2021-12-17 11:22:01 CET  49045 1000 1000 SIGSEGV missing      /usr/bin/shotwell                                 n/a
Thu 2022-01-06 23:54:16 CET   9219 1000 1000 SIGTRAP missing      /app/Signal/signal-desktop                        n/a
Mon 2022-01-10 21:42:06 CET   2407 1000 1000 SIGSEGV missing      /usr/bin/wireplumber                              n/a
Mon 2022-01-24 22:33:05 CET  43017 1000 1000 SIGSEGV missing      /usr/lib64/firefox/firefox                        n/a
Wed 2022-01-26 20:10:38 CET  11702 1000 1000 SIGSEGV present      /usr/bin/gnome-disks                             2.6M
Wed 2022-01-26 21:37:42 CET   9405 1000 1000 SIGSEGV present      /app/lib/noson/noson-gui                        14.2M
Wed 2022-01-26 21:49:46 CET   3940    0    0 SIGSEGV inaccessible /usr/sbin/dumpe2fs                                n/a
Wed 2022-01-26 21:50:47 CET   4295 1000 1000 SIGABRT present      /usr/bin/gnome-disks                             2.1M

No gdm or gnome-session coredumps…

1 Like
2

This doesn’t look like the (direct) cause of a crash. This is an assertion check along the lines of:

void
g_object_unref (gpointer object)
{
  g_return_if_fail (G_IS_OBJECT (object));

  // etc...
}

Which will log a critical message if object is not a GObject. The reason why you have been recommended to use G_DEBUG=fatal-criticals, is because it will turn the critical into a crash so that you can find out where the call is happening. The reason there is no core dump for gdm, is that it appears that gdm is not crashing.

Although, this is a bug that should be fixed, I would wager the cause of your crash is instead in the core dump for gnome-shell. There certainly shouldn’t be any core dumps for that process.

1 Like
3

Thanks for your reply!

How do I set this env variable?

4

I suppose you could add this to /etc/profile, however if any other programs throw criticals they will also crash. You may be better off adding --fatal-warnings to the ExecStart line in /usr/lib/systemd/system/gdm.service, but I am not familiar with debugging gdm.

To re-iterate: it does not seem like gdm is crashing. On the contrary, this seems like a relatively harmless warning, probably unrelated to what is actually crashing.

5

Let me provide some more content form my journal from around the time of suspend and wake-up.

  • suspending at 10:30:16 (last line)
  • resuming at 10:30:30.

There is a weird error in line 84 at 10:30:58, which I don’t understand, but it looks a lot like a crash of gnome-shell.

I can see that I was able to login only at 10:31:23 where I mistyped my password on login. Up to 10:31:23, GDM is frozen

Log: https://augenauf.fedorapeople.org/logs.txt.log

6

10:30:58 gnome-shell: JS ERROR: Gio.IOErrorEnum: Error calling StartServiceByName for net.reactivated.Fprint: Timeout was reached

This is just telling you the fingerprint daemon timed out trying to start. The timeout for a call like that would probably be about 25 seconds.

I don’t see anything in your log that indicates something has crashed. If you do think something has crashed, you should check for a core dump at around ~10:30. If there isn’t one, I would guess that you aren’t experiencing a crash at all, but rather something hanging when you come out of suspend.

7

coredumpctl list does not show any crashes around 10:30.

Could the fprint daemon be the cause for the hanging? How would I disable it completely since my Thinkpad T450s does not even have a fingerprint reader.

Another thing I noted, it doesn’t matter if I suspend the system from and X11 or wayland session. Both hang upon waking up.

8

Problem solved

I removed packages

    Removed fprintd-1.94.1-1.fc35.x86_64     @@System
    Removed fprintd-pam-1.94.1-1.fc35.x86_64 @@System
    Removed libfprint-1.94.2-1.fc35.x86_64   @@System

and the damn hang is gone. fprintd somehow causes a timeout in which the entire machine is hanging.

EDIT: bug filed here against fprintd (not sure that is actually correct): 2048819 – Resume from suspends hangs until a timeout reached (GDM/Gnome). removed fprintd = OK

3 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.