Did you check whether gnome-settings-daemon was still running? Or if it's somehow unresponsive? In both cases, a backtrace of the crash or hang would be appreciated.

Created attachment 301454 [details]
Output of gnome-settings-daemon -r

Thanks for your reply. There are always two instances of gnome-settings-daemon running, one instance as the user "gdm" and one as a normal user. Restarting gnome-settings-daemon does not seem to have an effect on this bug.

You can find the output of gnome-settings-daemon -r in the attached textfile. Let me know if you need any additional information.

Which distro is this on? We've had another bug report with the same symptoms and the reporter says it stopped happening with GNOME 3.16 . See bug 745753

This is happening on Ubuntu 15.04 with the GNOME 3 PPA (3.16). It's indeed a duplicate of bug 745753.

The output of "dbus-monitor --session --profile | grep ^sig" and xev is the same as in the other bug report. Nothing gets logged by gsd when I press any of the non-functioning keybindings (like Ctrl+Alt+T and XF86AudioLowerVolume).

I can confirm this on Ubuntu 15.04 with the GNOME 3 PPA.

After looking into this further, I'm getting the same results as the reporter:

 * Logging from from xev and are dbus-monitor the same as bug 745753
 * Nothing is logged after launching gsd in debug mode

However, I noticed that launching gsd with --replace didn't actually replace the the instance started at login. So I tried sending a SIGTERM to it with no result - it was only terminated after sending a SIGKILL. It was then automatically restarted (by gnome-session? systemd?) and media keys (and my lock screen shortcut) started working again.

After then running `gsd --debug --replace` once more, my session was terminated and I had to log back in.

Note this is with systemd used as process 1.

According to strace, after resuming from suspend and un-SIGTERM'able, it's stuck in a futex:

> futex(0x7fda2e102568, FUTEX_WAIT_PRIVATE, 421, NULL

This is the stack gdb reports at this point:

+ Trace 234995

(In reply to Michael Gratton from comment #7)
> According to strace, after resuming from suspend and un-SIGTERM'able, it's
> stuck in a futex:
> 
> > futex(0x7fda2e102568, FUTEX_WAIT_PRIVATE, 421, NULL
> 
> This is the stack gdb reports at this point:

Can you install the debug version of the glib and gnome-settings-daemon packages and get the gdb output again?

I worked out how to reproduce this with gsd 3.16.1:

1. Suspend with an external USB keyboard/mouse plugged in
2. When it has suspended, unplug the keyboard
3. Wake the computer

Media keys and other gsd-managed shortcuts will no longer work.

Stack trace with gsd and glib debugging symbols:

+ Trace 234996

I can confirm this and add that in my case even shortcuts like Ctrl-Alt-T doesn't work any more (although the basic ones for window manipulation still works).
For me it's a matter of locking the screen, and unlocking it.
After the screen is unlocked all of the shortcuts stop working.

Problem looks to be somewhere in the GsdDeviceManager.

Any chance you could move away the gnome-settings-daemon binary:
mv /usr/lib/gnome-settings-daemon/gnome-settings-daemon /usr/lib/gnome-settings-daemon/gnome-settings-daemon.bak

Kill the running instance:
killall -9 gnome-settings-daemon (ignore the errors)

Run the daemon under valgrind:
valgrind /usr/lib/gnome-settings-daemon/gnome-settings-daemon.bak

Reproduce the problem, and send the output of that tool to us. I'd also need to know the exact version of gnome-settings-daemon.

(Don't forget to move the binary back in its place, and reboot to clean up that state).

Created attachment 304583 [details]
Valgrind output

Thank you for the instructions. Valgrind didn't give any output when suspending or resuming from suspend; see the attachment. This is running gsd 3.16.2-0ubuntu1~vivid1 from GNOME 3 PPA.

This is what's causing everything to hang:
(gnome-settings-daemon.bak:16757): GLib-GObject-WARNING **: cannot register existing type 'GsdDeviceManager'

(gnome-settings-daemon.bak:16757): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(gnome-settings-daemon.bak:16757): common-plugin-CRITICAL **: gsd_device_manager_list_devices: assertion 'GSD_IS_DEVICE_MANAGER (manager)' failed

You'll probably want to ask Ubuntu GNOME to review the patches they're using in their PPA, because we haven't seen that particular error on other distributions.

I have linked this bug to Launchpad: https://bugs.launchpad.net/gnome-settings-daemon/+bug/1427877

Created attachment 305899 [details]
gdb breakpoints on gsd_device_get_device_type()

Hi there, I'm on also on the PPA facing the same issue. The error Bastien describes in #13 is not the root cause for me (The "GSD_IS_DEVICE_MANAGER" message appears way earlier in the initialization phase, but the media keys still work fine afterwards). 

I recompiled the ubuntu ppa package gnome-settings-daemon from source. Stripped the Debian Patches. Then I added some printf debugging, since I know nothing about the gnome code base, and changed gsd-xrandr-manager.c->manager_device_removed to

void
manager_device_removed (GsdXrandrManager *manager,
                        GsdDevice        *device)
{
        GsdDeviceType type;

        g_debug("here removed");
        type = gsd_device_get_device_type (device);

        if ((type & GSD_DEVICE_TYPE_TOUCHSCREEN) == 0)
                return;
        g_debug("here removed2");
        gsd_device_mapper_remove_input (manager->priv->device_mapper, device);
}

As you can see in #15 g_debug("here removed2") is never printed. So maybe something about the wiring of the singal/emit mechanism of ("device-removed", "device-added") is broken? In any case it leads to:


(gnome-settings-daemon:5635): GLib-GObject-WARNING **: cannot register existing type 'GsdDevice'

(gnome-settings-daemon:5635): GLib-GObject-WARNING **: cannot add private field to invalid (non-instantiatable) type '<invalid>'

(gnome-settings-daemon:5635): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

Unfortunately I could not identify where those logs lines come from. Maybe you can give me some pointers so I can investigate further?


The issue is also triggered when adding an external monitor.

removing the touchscreen conditional/return does seem to fix the hotkey issue.  I don't have any touchscreen devices though so not sure what it might break.

Not for my ThinkPad Extra Buttons (Fn/Vol+/Vol-) :(

But the manager_device_removed function is named very misleading or there is an error in !(type & GSD_DEVICE_TYPE_TOUCHSCREEN)) This holds true for non Touchscreen devices right? So only touchscreen devices are removed and added (manager_device_added has the same statement).

So I changed the code to:
        g_debug("here removed");
        type = gsd_device_get_device_type (device);
        g_debug("%s", g_type_name(G_TYPE_FROM_INSTANCE(device)));
        g_debug("device: %s %u %u", G_TYPE_FROM_INSTANCE(device), type, GSD_DEVICE_TYPE_TOUCHSCREEN);
        g_debug("%u", type & GSD_DEVICE_TYPE_TOUCHSCREEN);

I get the following output:

(gnome-settings-daemon:32578): xrandr-plugin-DEBUG: here removed

(gnome-settings-daemon:32578): GLib-GObject-WARNING **: cannot register existing type 'GsdDevice'

(gnome-settings-daemon:32578): GLib-GObject-WARNING **: cannot add private field to invalid (non-instantiatable) type '<invalid>'

(gnome-settings-daemon:32578): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' failed

(gnome-settings-daemon:32578): common-plugin-CRITICAL **: gsd_device_get_device_type: assertion 'GSD_IS_DEVICE (device)' failed
(gnome-settings-daemon:32578): xrandr-plugin-DEBUG: GsdDevice
(gnome-settings-daemon:32578): xrandr-plugin-DEBUG: device: \u0008 0 16
(gnome-settings-daemon:32578): xrandr-plugin-DEBUG: 0
(gnome-settings-daemon:32578): xrandr-plugin-DEBUG: here removed2

So GSD_IS_DEVICE fails for a GsdDevice. Unfortunately I don't know enough about GObject. Is it possible that there are competing definitions? I saw there is duplicate code and definitions in https://github.com/GNOME/gnome-control-center/blob/1cd186eaad29dd44fb1cbc71212655f5dc5c1edb/panels/common/gsd-device-manager.h .. Also after this happens I cannot change the brightness in the control panel. So maybe this an indicator as well.

Unfortunately I don't see where gsd_device_get_type (the function behind GSD_IS_DEVICE) is implemented, so I can compare why its failing to recognize the GsdDevice at hand.

hmm... on further inspection, it fixes it only temporarily.  enough unplug/replug of monitor and the hotkeys stop working again.

(In reply to Bastien Nocera from comment #13)
> This is what's causing everything to hang:
> (gnome-settings-daemon.bak:16757): GLib-GObject-WARNING **: cannot register
> existing type 'GsdDeviceManager'
> 
> (gnome-settings-daemon.bak:16757): GLib-CRITICAL **: g_once_init_leave:
> assertion 'result != 0' failed
> 
> (gnome-settings-daemon.bak:16757): common-plugin-CRITICAL **:
> gsd_device_manager_list_devices: assertion 'GSD_IS_DEVICE_MANAGER (manager)'
> failed
> 
> You'll probably want to ask Ubuntu GNOME to review the patches they're using
> in their PPA, because we haven't seen that particular error on other
> distributions.

If the problem isn't due to Ubuntu's PPA patches, then it might be Ubuntu's compilation and/or linking flags. You should really report this downstream, it doesn't happen on anything but Ubuntu...

So, I can confirm building gnome-settings-daemon from vanilla source does indeed leave the media-keys intact. (Not a workaround though, now back-light hotkeys want gksudo permission.) Taking it back to the Ubuntu bug tracker.

git clone git@github.com:GNOME/gnome-settings-daemon.git
cd gnome-settings-daemon
git checkout GNOME_SETTINGS_DAEMON_3_16_2
git submodule init
git submodule update
./autogen.sh
./configure
make
/usr/local/libexec/gnome-settings-daemon -r --debug

Great, thanks a lot for testing. I'll let you bring this bug back to Launchpad.

This was caused by linking with -Wl, -BSymbolic-functions, which for some reason seem to break the sharing of type info between plugins.

Apparently it seems no other distro's link with this flag, but just noting it here in case others hit the same issue

*** Bug 746777 has been marked as a duplicate of this bug. ***