GNOME Bugzilla – Bug 756160
Crash/segfault when dragging tabs (after 2nd/3rd/4th+ drag)
Last modified: 2015-10-17 19:46:42 UTC
When attempting to drag tabs around in an MSYS2 build of GTK 3.18.0 for the mingw-w64 "MINGW64" and "MINGW32" targets, everything works as it should for the first couple of drags. However after a small number of successful drags, the program segfaults: ------------------------8<------------------------------ $ python notebook-drag-minimal.py (python.exe:328): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed Segmentation fault ------------------------>8------------------------------ Sample test code: https://gist.github.com/achadwick/1b3505beb47d65fedfd6 It was originally written for testing a different bug also reported here, but it provokes this one too. This appears to be Windows-specific: I've not been able to provoke it in Debian unstable's GTK 3.18.0. The Gdk-CRITICAL does not appear to be directly associated with the crash: it can appear one or more times before the program crashes, in different click-drag-release sequences. System: Win7, recent MSYS2 install from the most recent installer, msys2-x86_64-20150916, https://msys2.github.io/ fully updated and tested both with and without debug builds of glib, gtk, and gdk. ------------------------8<------------------------------ Test User@win7test MINGW32 /g/MyPaintProject/mypaint $ gdb -ex r --args python notebook-drag-minimal.py GNU gdb (GDB) 7.10 [...] Reading symbols from python...(no debugging symbols found)...done. Starting program: c:\msys64\mingw32\bin\python.exe notebook-drag-minimal.py [New Thread 2932.0x1140] warning: Python failed to load the default activation context [New Thread 2932.0xf0c] [New Thread 2932.0x13c0] [New Thread 2932.0x118c] [New Thread 2932.0xfd0] [New Thread 2932.0x1314] (python.exe:2932): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed (python.exe:2932): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed (python.exe:2932): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed (python.exe:2932): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed (python.exe:2932): Gdk-CRITICAL **: gdk_cursor_get_display: assertion 'GDK_IS_CURSOR (cursor)' failed Program received signal SIGSEGV, Segmentation fault. gtk_css_style_is_static (style=style@entry=0x0) at gtkcssstyle.c:112 112 return GTK_CSS_STYLE_GET_CLASS (style)->is_static (style); (gdb) bt
+ Trace 235548
I'm using no special themes, just the builtin Adwaita.
Sorry, just to clarify: there are two traces in trace 235548: related area of code, and perhaps related, but different lines.
Another trace, this time from GTK 3.8.1: Program received signal SIGSEGV, Segmentation fault. 0x0000000070ec3f2d in gdk_cursor_get_display (cursor=0x481ba80) at gdkcursor.c:432 432 g_return_val_if_fail (GDK_IS_CURSOR (cursor), NULL); (gdb) bt
+ Trace 235550
Sorry, 3.18.1 above: from this PKGBUILD: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtk3. Identical symptoms to the original report, but the exception is now happening somewhere else. And another from my debugging build of 3.18.1: Program received signal SIGSEGV, Segmentation fault. g_type_check_instance_is_fundamentally_a ( type_instance=type_instance@entry=0x486a080, fundamental_type=fundamental_type@entry=80) at ../../glib-2.46.0/gobject/gtype.c:4028 4028 node = lookup_type_node_I (type_instance->g_class->g_type); (gdb) bt
+ Trace 235551
Yet a different function. What's going on here?
Here is an idea, maybe the win32 cursor theme support is not quite working as intended ? https://git.gnome.org/browse/gtk+/commit/?id=26c24328d57aa0c7d727008706c5d4aa46dac9b1
I've had dragging-related problems in my Windows Pidgin builds. If you drag conversation tabs around, it will eventually crash. Like this: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 6892.0x2010] g_type_check_instance_cast (type_instance=0x13454520, iface_type=138557904) at gtype.c:4060 4060 node = lookup_type_node_I (type_instance->g_class->g_type); (gdb) bt
+ Trace 235554
(gdb) p *impl->cursor $6 = {parent_instance = {g_type_instance = {g_class = 0x7653f80}, ref_count = 1108, qdata = 0x0}, display = 0x55ce000, type = GDK_LEFT_PTR} (gdb) p *(GdkWin32Cursor*) impl->cursor $7 = {cursor = {parent_instance = {g_type_instance = {g_class = 0x7653f80}, ref_count = 1108, qdata = 0x0}, display = 0x55ce000, type = GDK_LEFT_PTR}, name = 0x85e2188 "left_ptr", hcursor = 0x10003} Object appears to be correct (hcursor and name members look plausible), not sure what the problem is with g_class.
I can confirm that merely reverting 26c24328d57aa0c7d727008706c5d4aa46dac9b1 *does not* fix the crashes seen when dragging tabs. From an MSYS2 mingw-w64-x86_64-gtk3-3.18.1-1 rebuilt with its *-debug buddy and a reverter patch for that commit grafted in locally: $ gdb -ex r --args python notebook-drag-minimal.py GNU gdb (GDB) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from python...(no debugging symbols found)...done. Starting program: c:\msys64\mingw64\bin\python.exe notebook-drag-minimal.py [New Thread 3360.0x1194] [New Thread 3360.0x1338] [New Thread 3360.0xc58] [New Thread 3360.0xed4] [New Thread 3360.0x13ec] [New Thread 3360.0xf94] Program received signal SIGSEGV, Segmentation fault. gtk_css_style_is_static (style=style@entry=0x0) at gtkcssstyle.c:114 114 return GTK_CSS_STYLE_GET_CLASS (style)->is_static (style); (gdb) bt
+ Trace 235558
57 GtkCssChange change, 58 gint64 timestamp, 59 GtkCssStyle *style) 60 { 61 /* This should get rid of animations */ 62 return GTK_CSS_NODE_CLASS (gtk_css_transient_node_parent_class)->update_style (cssnode, change, 0, style); 63 } 64 65 static void 66 gtk_css_transient_node_class_init (GtkCssTransientNodeClass *klass) (gdb) q Not sure what I'm looking for here, sorry. It doesn't look cursor-related, however.
This is still happening in 3.18.2: $ gdb -ex r --args python ./notebook-drag-minimal.py GNU gdb (GDB) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from python...(no debugging symbols found)...done. Starting program: c:\msys64\mingw64\bin\python.exe ./notebook-drag-minimal.py [New Thread 3208.0xcc8] [New Thread 3208.0x1534] [New Thread 3208.0x15ac] [New Thread 3208.0x1108] [New Thread 3208.0x1708] Program received signal SIGSEGV, Segmentation fault. g_type_check_instance_is_fundamentally_a ( type_instance=type_instance@entry=0x3cd0680, fundamental_type=fundamental_type@entry=80) at ../../glib-2.46.0/gobject/gtype.c:4028 4028 node = lookup_type_node_I (type_instance->g_class->g_type); (gdb) bt
+ Trace 235580
It's easy to test with tests/testnotebookdnd.exe too: In gdk_cursor_get_display(): $ gdb -ex r --args testnotebookdnd.exe GNU gdb (GDB) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-w64-mingw32". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from testnotebookdnd.exe...done. Starting program: G:\MyPaintProject\mypaint\testnotebookdnd.exe [New Thread 4516.0xa84] [New Thread 4516.0xa90] [New Thread 4516.0x1558] [New Thread 4516.0x17f4] [New Thread 4516.0xcec] page 3 reordered (testnotebookdnd.exe:4516): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed page 2 reordered (testnotebookdnd.exe:4516): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed page 1 reordered (testnotebookdnd.exe:4516): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Program received signal SIGSEGV, Segmentation fault. 0x0000000070ec3f2d in gdk_cursor_get_display (cursor=0x3f8dd00) at gdkcursor.c:432 432 g_return_val_if_fail (GDK_IS_CURSOR (cursor), NULL); (gdb) (gdb) (gdb) bt
+ Trace 235582
Should mention that 3.16.6 is *I think* free of this bug. From LRN on IRC, for anyone with more gdb-fu than me right now: <LRN> well, i've been thinking a bit about this <LRN> it's difficult to debug * tristan has quit (Connection reset by peer) <LRN> the only thing i can think of is: 1) find an easy way to reproduce it (as little code as possible and as little user actions as possible) <LRN> 2) find where it crashes 3) set up a breakpoint where it crashes 4) break on the breakpoint, observe the values that could be the source of the crash 5) disable the breakpoint 6) let it crash <LRN> 7) observe the values at the moment of crashing, compare with previous observations 8) redo the process, putting a watchpoint at the value that changed (and caused the crash) during (4) hopefully, watchpoint will trigger when the value that caused the crash changes bisecting could work as well, but only if there is a version that is known to work <LRN> (for all i know this bug could have been there for years) (it is implied that between (5) and (7) the point of crash is visited multiple times without crashing) from the backtraces it seems that the crash point is somehow related to the type system
Another datapoint when testing (with glib2 2.46.1 and gtk3 3.18.2): To reproduce, you have to drag the tab out of its parent notebook. Moving the tab carefully within its parent notebook so that the drag preview "icon" is not displayed at the pointer at any point does not crash the program.
Bisecting done. Looks like 641fbd86d796bb0f7838b1d7387031a106386439 and probably 26c24328d57aa0c7d727008706c5d4aa46dac9b1 too need to be reverted. -------------------------------------8<------------------------------- Test User@win7test MINGW64 /usr/src/gtk+ $ git bisect good 641fbd86d796bb0f7838b1d7387031a106386439 is the first bad commit commit 641fbd86d796bb0f7838b1d7387031a106386439 Author: Руслан Ижбулатов <lrn1986@gmail.com> Date: Sun May 3 21:29:35 2015 +0000 GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR In particular this means that cursors are disposed of by the way of g_object_unref(), not DestroyCursor (which is documented to not to be used on certain kinds of cursors, and we can't tell which is which). It should also alleviate any concerns about destroying cursors that are still in use by other windows, except for cases where we would somehow get our hands on a HCURSOR that someone else is using and we make a GdkCursor out of it and later unref and finalize it while it is still in use. It also removes the need to call CopyCursor(), which makes animated cursors into non-animated ones as a side-effect (supposed to be a bug, but try explaining that to MS). Now cursors should be animated (if the are set up as such in the OS). https://bugzilla.gnome.org/show_bug.cgi?id=697477 :040000 040000 d28077ec0efd62b2a03ed33ad57fa83d05ab2457 a1bb0ab6d6b6729b01d7193c5a8d6eda4dfeb089 M gdk -------------------------------------8<------------------------------- $ git bisect log git bisect start # bad: [294dd9757af8d27cf2f68cd5a38b2849bedfbf8f] 3.18.0 git bisect bad 294dd9757af8d27cf2f68cd5a38b2849bedfbf8f # bad: [faeaa2f91ee9561f36cc6f66df6bdeb46eb16f88] 3.17.9 git bisect bad faeaa2f91ee9561f36cc6f66df6bdeb46eb16f88 # good: [06984006a5749ae39772a156e6b1ec29bd1fb919] 3.17.1 git bisect good 06984006a5749ae39772a156e6b1ec29bd1fb919 # bad: [7db399d975b8f9626c21761dde5f2d5feeb6e305] placessidebar: add Other Locations item git bisect bad 7db399d975b8f9626c21761dde5f2d5feeb6e305 # bad: [995e87322c01d22290e122a88d8d1ff3091ce1a3] file chooser: Remove some obsoltete code git bisect bad 995e87322c01d22290e122a88d8d1ff3091ce1a3 # bad: [d3212c9b46cba09ec2c0ea2f9c02d9a92acbbc45] Updated Hungarian translation git bisect bad d3212c9b46cba09ec2c0ea2f9c02d9a92acbbc45 # bad: [c207b8d36341d320ca3bf88ece63d2721a63c7b6] Bump Pango requirement git bisect bad c207b8d36341d320ca3bf88ece63d2721a63c7b6 # bad: [833dbd65cd582346aa52e7dbb122e0e709cd3b7b] Trivial: Use a convenience macro git bisect bad 833dbd65cd582346aa52e7dbb122e0e709cd3b7b # good: [7d83edd4e01b34e83474f8b8b49d3e6c3acb610d] Update docs git bisect good 7d83edd4e01b34e83474f8b8b49d3e6c3acb610d # good: [f6d021512a3d076c8a559e52ea1d1c84ff5c4154] GtkWindow: Don't assume no shadow width even when not supported git bisect good f6d021512a3d076c8a559e52ea1d1c84ff5c4154 # bad: [fe6e5d3116fcf5c812534d7344e3aa3cfc5f6e1c] 3.17.2 git bisect bad fe6e5d3116fcf5c812534d7344e3aa3cfc5f6e1c # bad: [f00214e92206117a85b933745f89e5c998024c3d] scrolledwindow: reset more Indicator state on ::unmap git bisect bad f00214e92206117a85b933745f89e5c998024c3d # bad: [2ba7977114776de22afbba6b8ec61d0fe8c57a2d] gtk3-demo: Fix Visual Studio Builds git bisect bad 2ba7977114776de22afbba6b8ec61d0fe8c57a2d # good: [4e9be39518edbd1cbaa5959598d43d8415a32195] wayland: Add global object depedency tracking git bisect good 4e9be39518edbd1cbaa5959598d43d8415a32195 # bad: [641fbd86d796bb0f7838b1d7387031a106386439] GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR git bisect bad 641fbd86d796bb0f7838b1d7387031a106386439 # good: [7fef713224583ab906d0875eedcf7a76534eff0f] wayland: Use on globals closure for loading cursor themes git bisect good 7fef713224583ab906d0875eedcf7a76534eff0f # first bad commit: [641fbd86d796bb0f7838b1d7387031a106386439] GDK: Use GdkCursor objects to keep track of W32 cursors, not HCURSOR
Testing was of necessity done with https://git.gnome.org/browse/gtk+/commit/?id=9fbd71394c172d783422622d9acd32c68d748701 applied at points before it hit master in order to run tests/testnotebookdnd.exe, so I'm testing a reverter for those two commits on top of the current HEAD just to be sure.
Created attachment 313502 [details] [review] 0001-Revert-GDK-cursor-theme-support-for-win32-backend.patch Patch against recent master attached that reverts the recent changes to support cursor themes. I've tested that it resolves this issue, but it's a pretty ugly and wasteful way of fixing this relatively obscure bug :( Anyone else able to analyse the real problem here and fix this issue more subtly?
Reproduced the crash in testnotebookdnd. It was due to w32 version of gdkdevice-virtual not getting a reference on a cursor it uses. Will upload a patch shortly.
Created attachment 313519 [details] [review] W32: Add missing reference taking in gdk_device_virtual_grab()
Review of attachment 313519 [details] [review]: Marking as accepted on behalf of nacho who is sitting next to me without a pc
Comment on attachment 313519 [details] [review] W32: Add missing reference taking in gdk_device_virtual_grab() Attachment 313519 [details] pushed as 00b39e4 - W32: Add missing reference taking in gdk_device_virtual_grab()
Confirm that this is fixed in gtk+ master as of 25483304cdc967c374a435200416affb573583f8. Thanks, everyone!