gnome-shell crashed with SIGABRT in __GI___poll() from g_main_context_poll() from g_main_context_iterate() from g_main_loop_run() from g_dbus_connection_send_message_with_reply_sync() from g_dbus_connection_call_sync_internal() [method = "QueryFilesystemInfo", interface = "org.gtk.vfs.Mount"]

[Rocko]

The computer hard-locked up after I did a suspend/resume cycle and entered my password. I generated this via ssh'ing in from a phone and issuing a kill -ABRT command on my gnome-shell session pid.

This happens randomly but with annoying frequency and it happens whether I run gnome-shell in X or Wayland.

ProblemType: Crash
DistroRelease: Ubuntu 18.04
Package: gnome-shell 3.28.2-0ubuntu0.18.04.1
Uname: Linux 4.17.5-041705-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Fri Jul 13 18:57:15 2018
DisplayManager: gdm3
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/gnome-shell
ExecutableTimestamp: 1529538342
InstallationDate: Installed on 2017-08-16 (331 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Release amd64 (20170412)
ProcCmdline: /usr/bin/gnome-shell
ProcCwd: /home/rocko
ProcEnviron:
 LANGUAGE=en_AU:en
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
Signal: 6
SourcePackage: gnome-shell
StacktraceTop:
 raise (sig=<optimised out>) at ../sysdeps/unix/sysv/linux/raise.c:51
 ()
 <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
 __GI___poll (fds=0x55ddc16f8270, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
 () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
Title: gnome-shell crashed with SIGABRT in raise()
UpgradeStatus: Upgraded to bionic on 2017-11-17 (238 days ago)
UserGroups: adm bumblebee cdrom dip kvm lpadmin plugdev sambashare sudo

[Rocko (rockorequin)]

I can add that after killing the gnome-shell session, gnome-shell went back to the login screen, but when I tried logging in, the new gnome-shell session crashed.

[Apport retracing service (apport)]

StacktraceTop:
 __GI___poll (fds=0x55ddc16f8270, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
 g_main_context_poll (priority=<optimized out>, n_fds=1, fds=0x55ddc16f8270, timeout=<optimized out>, context=0x55ddc58078e0) at ../../../../glib/gmain.c:4204
 g_main_context_iterate (context=0x55ddc58078e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../../../../glib/gmain.c:3898
 g_main_loop_run (loop=0x55ddbf61e900) at ../../../../glib/gmain.c:4099
 g_dbus_connection_send_message_with_reply_sync (connection=connection@entry=0x55ddbfcb7d30, message=message@entry=0x55ddc4053d90, flags=flags@entry=G_DBUS_SEND_MESSAGE_FLAGS_NONE, timeout_msec=timeout_msec@entry=2147483647, out_serial=out_serial@entry=0x0, cancellable=cancellable@entry=0x0, error=0x7ffdcb8ffa10) at ../../../../gio/gdbusconnection.c:2151

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Thanks for doing this.

If the lockup is in gnome-shell then the only slightly suspicious information I can see relates to:

        target_method_name = 0x7fd923379223 "QueryFilesystemInfo"
        target_interface_name = 0x55ddc48f43e0 "org.gtk.vfs.Mount"

so something might be stuck querying your home directory. Does it exist on a special/remote drive? Or with an unusual filesystem?

[Rocko (rockorequin)]

I don't think there's anything particularly unusual about my home folder. I formatted the root partition as btrfs instead of ext4 when I did the installation, so the Ubuntu installer put /home into its own subvolume. I also asked the installer to encrypt the home folder, so it's encrypted with ecryptfs.

[Daniel van Vugt (vanvugt)]

Yeah, I'm not saying that's wrong. It's just the only explanation I can think of because your gnome-shell seems to be stuck in gvfs code querying the (encrypted) home directory. If correct then that's just a bug.

Unfortunately I haven't yet found any other reports of such a hang, but that also would be because we don't get automated hang reports, only automated crash reports. So this might be a common problem and we'd never know.

Before going so far as to ask you to test with a non-encrypted directory we need to check the most common cause of bugs first. That is third-party extensions. Please disable all your extensions and let us know if the problem then goes away...

b'org.gnome.shell' b'enabled-extensions' b"['<email address hidden>', '<email address hidden>', 'multi-volume@tigersoldier', '<email address hidden>', '<email address hidden>', '<email address hidden>', '<email address hidden>', '<email address hidden>', 'AdvancedVolumeMixer_harry.karvonen.gmail.com', 'mconnect_andyholmes.github.io', 'mediaplayer_patapon.info', 'openweather-extension_jenslody.de', 'drive-menu_gnome-shell-extensions.gcampax.github.com', 'ubuntu-dock_ubuntu.com', 'system-monitor_paradoxxx.zero.gmail.com', 'dock-settings@lagrangian', 'dash-to-dock_micxgx.gmail.com', '<email address hidden>', '<email address hidden>', '<email address hidden>', '<email address hidden>', 'suspend-button@laserb', 'activities-config@nls1729', '<email address hidden>', '<email address hidden>', 'extension-reloader@nls1729']"

Start by disabling drive-related extensions like the drive-menu ones...

[Rocko (rockorequin)]

Ok, I have started by disabling Removable Drive Menu and System Monitor and so far, so good. (But since it's random, it might take a while to reproduce anyway.)

So gnome-shell doesn't enforce any sort of timeout for non-responsive extensions?

[Daniel van Vugt (vanvugt)]

No, the power of gnome-shell's extensibility is also its weakness.

Basically everything in gnome-shell is a global that extensions can modify directly or indirectly. That's what makes so many extensions possible, but it also means that they are not isolated. So any bug in an extension can easily break the whole shell. And that's what often happens.

[Rocko (rockorequin)]

So far there have been no lockups since I disabled those two, so I've re-enabled Removable Drive Menu to see if that causes the lockups to return.

[Daniel van Vugt (vanvugt)]

Thanks. Though we don't need to wait for the result of further testing to believe the bug is not in gnome-shell.

If you find the bug is in an extension that is offered by the Ubuntu archive then we should reopen it as a task against that extension.

[Rocko (rockorequin)]

Just for completeness, there have been no more crashes with Removable Drive Menu enabled, so it is likely that System Monitor was the culprit.

[Daniel van Vugt (vanvugt)]

Thanks. Ugh, System Monitor seems to have caused a couple of bugs...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.