GNOME Bugzilla – Bug 646607
Paint tools, Text tool: Click and drag font/brush/pattern/gradient from tool options crashes GIMP
Last modified: 2018-05-24 12:59:43 UTC
In order to reproduce this bug I follow these 3 simple steps. 1. Open gimp and select "Text Tool" 2. Select a font from the "Tool Options" pane 3. Return to the previous pane, carefully reselect the highlighted font, click AND drag it. Gimp immediately crashes with no warning. This apparently is not needed because dragging the font has no known functionality but it was accidentally discovered.
Confirming with 2.6.11 on Windows XP.
Happens on X11 too and crashes deep inside GTK+. Will try to fix it in GTK+, but will not reassign the bug, because I need a reminder.
I tried to reproduce with GIMP 2.8.2 on Win7, 32 bit, but failed. Can you reproduce on your system with the current GIMP from gimp-win.sourceforge.net and report back, please? Also which is the 'previous pane' you mentioned in step 3? The only pane where I can drag fonts from ist the 'Fonts' pane. Where did you try to drop the font onto? The last sentence in your report lets assume that this isn't a very regular use case. Would you thus agree to set the priority down to 'minor'? Your answer within the next 6 weeks is appreciated. Thank you in advance.
I tried to reproduce with GIMP 2.8.2 on Win7 (32 bit), Mac OS X (native GIMP build) and on Linux but failed again. Closing this bug report as it could neither be reproduced nor further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Happens each time, you have to drag the already selected font.
scl: It appears you need to drag on the font's name for this to crash the GIMP, not on the small square preview thing. Also, this happens with more than just the fonts dialog - it happens with gradients, patterns, etc too in the list view.
Created attachment 231183 [details] Stacktraces After these clearer instructions I could reproduce it, too. Here are my results: Linux, Windows builds: Dragging the names in the fonts, brush, pattern and gradient selection lists in the Paint tool options cause GIMP to crash. I could fetch some stack-traces on Windows (see attachments). (At least every one contains the failing module and a register dump. The font and brush are complete.) The following actions don't cause crashes: - dragging the icons instead (in list or grid view), - dragging the name or icon from the separate Fonts, Brushes, Patterns or Gradients tabs, - dragging the name or icon from the Dynamics selection lists in the Paint tool options. Native Mac build: no crashes I suggest: In the context of selecting a list item for a tool option there's no need to drag items. We should therefore disable the dragging functionality here, like already implemented the Dynamics list. Adding the gnome-love keyword as this could probably be done by copy&paste from the Dynamics list view.
Are these really stack traces? They make no sense whatsoever, the functions next to each other don't call each other.
Sven, the best way to generate a stacktrace on windows is using mingw's port of gdb. (If you're copying from the windows crash report dialogs, the information there isn't really useful.) I was able to get a stack trace of this on linux, but my gtk+ and glib don't have debug symbols. The error seems to occur entirely in glib's event loop, so there wasn't anything useful in my stacktrace.
Created attachment 233386 [details] Stacktrace from IRC This stacktrace was provided today from user SKB in IRC. At a first glance it gives deeper insight into the gtk+ and glibs actions than the stacktraces before - so perhaps it's more useful. Thank you to SKB.
I can no longer reproduce this with latest 2-8 or master, on GTK+ 2.24.18. Does anyone still see this crash?
I can still reproduce this, on both latest 2.8 and master, with gtk+ 2.24.18
I reproduced it running with valgrind, whose first invalid read report is: Invalid read of size 8 at 0x53CA259: gtk_drag_begin_internal (gtk-2-24/gtk/gtkdnd.c:2362) by 0x53CAD5A: gtk_drag_source_event_cb (gtk-2-24/gtk/gtkdnd.c:3758) by 0x529011B: _gtk_marshal_BOOLEAN__BOXED (gtk-2-24/gtk/gtkmarshalers.c:86) by 0x870F10F: g_closure_invoke (glib/gobject/gclosure.c:777) by 0x87214BF: signal_emit_unlocked_R (glib/gobject/gsignal.c:3582) by 0x8728CAE: g_signal_emit_valist (glib/gobject/gsignal.c:3336) by 0x87298D1: g_signal_emit (glib/gobject/gsignal.c:3382) by 0x53AA41D: gtk_widget_event_internal (gtk-2-24/gtk/gtkwidget.c:5010) by 0x528DEE3: gtk_propagate_event (gtk-2-24/gtk/gtkmain.c:2490) by 0x528E24A: gtk_main_do_event (gtk-2-24/gtk/gtkmain.c:1685) by 0x57E9FCB: gdk_event_dispatch (gtk-2-24/gdk/x11/gdkevents-x11.c:2403) by 0x8997A74: g_main_context_dispatch (glib/glib/gmain.c:3058) by 0x8997DB7: g_main_context_iterate.isra.22 (glib/glib/gmain.c:3705) by 0x8998219: g_main_loop_run (glib/glib/gmain.c:3899) by 0x483196: app_run (gimp/app/app.c:256) by 0x482C8D: main (gimp/app/main.c:438) Address 0x11013090 is 0 bytes inside a block of size 16 free'd at 0x4A077E6: free (/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c:446) by 0x899D97E: g_free (glib/glib/gmem.c:197) by 0x89B302E: g_slice_free1 (glib/glib/gslice.c:1124) by 0x53C4F41: gtk_drag_source_site_destroy (gtk-2-24/gtk/gtkdnd.c:3780) by 0x580C9A: gimp_container_tree_view_set_container (gimp/app/widgets/gimpcontainertreeview.c:538) by 0x5836D3: gimp_container_view_set_container (gimp/app/widgets/gimpcontainerview.c:395) by 0x583890: gimp_container_view_private_dispose (gimp/app/widgets/gimpcontainerview.c:275) by 0x870F10F: g_closure_invoke (glib/gobject/gclosure.c:777) by 0x87214BF: signal_emit_unlocked_R (glib/gobject/gsignal.c:3582)
It appears to happen only when you select and drag the NAME of a font from the "tools options dialog" (not the preview letters in front of the name) and I also noticed that it doesn't happen in the "fonts dialog". (Gimp version 2.8.2, Ubuntu 12.10, gtk+ 2.24.13)
In master branch, this bug also appears on the gimppickablepopup used to provide a drawable for aux input pads of gegl operations. To reproduce: - open the Filters -> Map -> Bump map - click on the Aux Input button - initiate a drag by clicking the name of either an image, a layer or a channel
On pc Debian x86-64 with Gimp sources updated some days ago, I could reproduce this by doing this: - Select Text tool - In tool options, select a font - select again Text tool - In tool options, click on same font (on fontname part) then start to drag it => crash Valgrind trace: 52 ==4387== Invalid read of size 8 53 ==4387== at 0x537C58A: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 54 ==4387== by 0x537D02E: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 55 ==4387== by 0x5246A7E: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 56 ==4387== by 0x8E7D2D4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 57 ==4387== by 0x8E8F03B: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 58 ==4387== by 0x8E971A4: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 59 ==4387== by 0x8E978FE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 60 ==4387== by 0x535DECB: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 61 ==4387== by 0x52451C3: gtk_propagate_event (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 62 ==4387== by 0x524565A: gtk_main_do_event (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 63 ==4387== by 0x57B8BBB: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.28) 64 ==4387== by 0x9108C3C: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1) 65 ==4387== Address 0x33f611f0 is 0 bytes inside a block of size 16 free'd 66 ==4387== at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 67 ==4387== by 0x537A339: gtk_drag_source_set_target_list (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) 68 ==4387== by 0x5A7450: gimp_dnd_data_source_remove (gimpdnd.c:976) 69 ==4387== by 0x5A84A7: gimp_dnd_viewable_source_remove (gimpdnd.c:1994) 70 ==4387== by 0x58EA84: gimp_container_tree_view_set_container (gimpcontainertreeview.c:551) 71 ==4387== by 0x5911D7: gimp_container_view_set_container (gimpcontainerview.c:395) 72 ==4387== by 0x591368: gimp_container_view_private_dispose (gimpcontainerview.c:275) 73 ==4387== by 0x8E7D2D4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 74 ==4387== by 0x8E8F03B: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 75 ==4387== by 0x8E97697: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 76 ==4387== by 0x8E978FE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) 77 ==4387== by 0x526C00F: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28)
Just some thoughts here. 1) in gimp_dnd_data_source_remove (app/widgets/gimpdnd.c) When using process to reproduce crash, I noticed that we never entered the block "if (targets[i].info != data_type)" so new_list was empty and it seemed it triggered the Valgrind trace retrieved in previous comment. So what about using a gboolean to record the fact that at least one time in the for loop, we enter inside the if instruction and, in this case only, we call gtk_drag_source_set_target_list ? 2) I locally tested the change indicated in 1) but had another segfault with another Valgrind trace: " gimp_display_shell_profile_update ==12080== Invalid read of size 8 ==12080== at 0x537C58A: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x537D02E: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x5246A7E: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x8E7D2D4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) ==12080== by 0x8E8F03B: signal_emit_unlocked_R (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) ==12080== by 0x8E971A4: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) ==12080== by 0x8E978FE: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) ==12080== by 0x535DECB: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x52451C3: gtk_propagate_event (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x524565A: gtk_main_do_event (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x57B8BBB: ??? (in /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0.2400.28) ==12080== by 0x9108C3C: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1) ==12080== Address 0x34650150 is 0 bytes inside a block of size 16 free'd ==12080== at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==12080== by 0x53776D1: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==12080== by 0x58EB32: gimp_container_tree_view_set_container (gimpcontainertreeview.c:557) ==12080== by 0x5911E7: gimp_container_view_set_container (gimpcontainerview.c:395) ==12080== by 0x591378: gimp_container_view_private_dispose (gimpcontainerview.c:275) ==12080== by 0x8E7D2D4: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4400.1) " This time it's at the call "gtk_drag_source_unset (GTK_WIDGET (tree_view->view))" in gimp_container_tree_view_set_container I noticed this call was in this if block: if (gimp_dnd_viewable_source_remove (GTK_WIDGET (tree_view->view), gimp_container_get_children_type (old_container))) but in this case, we did not remove the source! so what about a) in gimp_dnd_viewable_source_remove replace: gimp_dnd_data_source_remove (dnd_type, widget); return TRUE; by: return (gimp_dnd_data_source_remove (dnd_type, widget)); b) change gimp_dnd_data_source_remove to return a gboolean which would be FALSE when there was no change. Any thoughts? Remark: I can propose a patch if it makes sense or if at the contrary I wasn't clear (it indeed may be :-)), to explicit my thoughts. With this patch, I had no crash but noticed this: (gimp-2.9:23646): Gdk-CRITICAL **: IA__gdk_pointer_grab: assertion 'window != NULL' failed
Can you attach the patch please?
Created attachment 310947 [details] [review] proposed patch Rebased today (7160e053496876e541f3d8809e347d5c9f20b432)
I was just about to try your patch, but could not reproduce the bug any, not in master and not in gimp-2-8. Your patch looks good anyway, will clean up and apply it.
Pushed a modified patch to master and gimp-2-8. Can anyone confirm that this changes anything? I'm love to close this as FIXED. commit bfd482755b081be7dbda2fd1d457d1b6b7ace8a8 Author: Julien Nabet <serval2412@yahoo.fr> Date: Tue Sep 8 21:34:11 2015 +0200 Bug 69496 - Paint tools, Text tool: Click and drag font/brush/pattern/gradient... ...from tool options crashes GIMP Applied a modified patch that actually removes the target list if it became empty. This may or may not fix the bug; I can't tell because I couldn't reproduce it any longer. (cherry picked from commit 456d535232ce781ffbb5f28d68dc91308154c0f8) app/widgets/gimpdnd.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
I still get a gazillion of invalid reads and use of free'd stuff in valgrind, so I guess this patch improves nothing.
(In reply to Michael Natterer from comment #21) > Pushed a modified patch to master and gimp-2-8. Can anyone confirm > that this changes anything? I'm love to close this as FIXED. > No it doesn't change enough. The problem is here: https://git.gnome.org/browse/gtk+/tree/gtk/gtkdnd.c?h=gtk-2-24#n2357 when gtk starts a drag it adds a grab and the popup receives a grab-notify event during which it cancels and destroys itself: https://git.gnome.org/browse/gimp/tree/app/widgets/gimppopup.c#n115 https://git.gnome.org/browse/gimp/tree/app/widgets/gimppopup.c#n244 after gtk_grab_add returns the target_list and the widget itself are gone. This does not happen clicking on a non selected font-name because in that case the popup is destroyed earlier following a signal generated by the context for the font change.
(In reply to Michael Natterer from comment #22) > I still get a gazillion of invalid reads and use of free'd stuff > in valgrind, so I guess this patch improves nothing. I can still reproduce the crash with the patch pushed. I'm trying to understand what should trigger the crash this between the initial patch proposed and the pushed one.
here's the Valgrind trace with master sources updated today: ==4359== Address 0x352de4f0 is 0 bytes inside a block of size 16 free'd ==4359== at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4359== by 0x5379339: gtk_drag_source_set_target_list (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.28) ==4359== by 0x5A6B76: gimp_dnd_data_source_remove (gimpdnd.c:985) ==4359== by 0x58E104: gimp_container_tree_view_set_container (gimpcontainertreeview.c:551) ==4359== by 0x590857: gimp_container_view_set_container (gimpcontainerview.c:395)
Created attachment 311206 [details] [review] Quick and dirty hack This is a drastic quick and dirty hack that prevents to set or unsets drag source capabilities from widgets inside GTK_WINDOW_POPUP toplevels.
OMG :) But indeed, seeing the GTK+ lines you pasted reminds me of my own debug attempts quite a while ago, and this looks damn familiar :/ I don't know if it's fixed in GTK+ 3.x, but until it is, we clearly need some evil hack like this, but please not that evil ;) I'll try to come up with another hack, and fall back to this one if I fail...
Mitch,
Comment on attachment 310947 [details] [review] proposed patch comment 21
Comment on attachment 311206 [details] [review] Quick and dirty hack comment 27
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/365.