GNOME Bugzilla – Bug 765996
Frequently hotplugging a Wacom device causes g-s-d segfault
Last modified: 2016-08-22 18:26:56 UTC
Created attachment 327309 [details] g-s-d segfault gdb log When frequently connecting/disconnecting a Wacom USB tablet, g-s-d resets a running window session to login prompt. A gdb tracelog shows the issue was caused by a NULL return value from open_device (device). gdb output is attached.
Is this really with GNOME 3.14? Which distribution ships that? Does this happen with newer versions as well?
The testing was on the latest CentOS 7. "gnome-session --version" on the system tells me it's 3.14. The issue does not always bring window back to login prompt. But, the segfault is reproducible. Use a script to repeatedly load/unload wacom kernel driver is an easier way to trig the issue.
It might also happen with newer versions.
Created attachment 329094 [details] Backtrace with GNOME 3.20 This issue is definitely still present in newer releases as well. See the attached backtrace from my Arch Linux box which has gnome-settings-daemon 3.20.1-1 installed.
Created attachment 329095 [details] Script to trigger segfault The attached script can be used in debugging this issue to trigger the segfault on a machine which has a Wacom tablet connected. All it does repeatedly load and unload the 'wacom' kernel module (so you'll probably need to run it as root) with a small random delay between each step. Triggering the segfault may take anywhere from a few seconds to a few minutes depending on your luck.
Can you test with the patch from https://bugzilla.gnome.org/show_bug.cgi?id=766726 ?
Looks like that patch does stop the segfaults, though I do see that g-s-d still occasionally terminates (much less than before) due to various G_LOG_LEVEL_ERROR messages. See the following distinct backtraces: [Backtrace 1]
+ Trace 236305
Ping
(In reply to Jason Gerecke from comment #8) > Ping This isn't useful. A patch would be useful. Everybody's busy. Seeing as the crash happens when we call gdk_display_sync(), it looks like there's some X calls that aren't wrapped by trap_push()/pop() and that the backtraces were gathered without running X calls synchronously. Run gnome-settings-daemon with GDK_SYNCHRONIZE=1 and reproduce the problem. The assertion (or crashers) should happen when the X calls actually fail, not the next time we look at the X loop.
Created attachment 330973 [details] [review] Fix for the crash bug Thanks for the GDK_SYNCHRONIZE=1 tip, that made things deterministic enough to pinpoint the problem areas. Now that I've been able to do that, I've been able to write up that patch you were hoping would appear ;)
Created attachment 330974 [details] [review] Bonus memory leak fixes I also noticed a few memory leaks while running g-s-d under valgrind and have created a patch for them as well.
Any chance of these patches getting pulled into master before the code freeze three weeks hence?
Gee, indeed, sorry about this. Although, might be "in vain", After wayland tablet v2 support was merged in master, I'm looking into implementing the mutter tablet configuration bits in mutter for x11/libinput. If I get that in time the g-s-d wacom plugin/settings will be phased out. Still, worth to push in the mean time, even backport. I am doing that now.