After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791447 - Segmentation fault, probably triggered by using the Color Picker Tool
Segmentation fault, probably triggered by using the Color Picker Tool
Status: RESOLVED DUPLICATE of bug 784480
Product: GIMP
Classification: Other
Component: libgimp
git master
Other Linux
: Normal blocker
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-12-10 18:51 UTC by Elle Stone
Modified: 2018-01-16 20:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
do not compute device coords in inferior_ignore_mode (4.24 KB, patch)
2017-12-15 13:39 UTC, Massimo
none Details | Review

Description Elle Stone 2017-12-10 18:51:48 UTC
Twice recently (currently using GIMP 2.9.7 commit 7fce78b2ce) GIMP 2.9.7 has crashed in connection with using the Color Picker Tool. The last time (just now) I was somewhat expecting a crash and so can say for sure that the crash occurred immediately after selecting the Color Picker Tool and attempting to color pick from the XCF file that I'd been working on. 

This is on Gentoo Linux. Here's the stack trace:

/home/elle/code-install/gimpdefault/install/bin/gimp-2.9: fatal error: Segmentation fault
/home/elle/code-install/gimpdefault/install/bin/gimp-2.9 (pid:4688): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s
  • #0 waitpid
    from /lib64/libpthread.so.0
  • #1 g_on_error_stack_trace
  • #2 g_on_error_query
    from /usr/lib64/libglib-2.0.so.0
  • #3 gimp_eek
  • #4 gimp_fatal_error
  • #5 gimp_sigfatal_handler
  • #6 <signal handler called>
  • #7 ??
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #8 gdk_device_get_state
  • #9 gimp_device_info_get_device_coords
  • #10 gimp_device_info_get_event_coords
  • #11 gimp_display_shell_get_event_coords
  • #12 gimp_display_shell_canvas_tool_events
  • #13 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #14 g_closure_invoke
  • #15 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #16 g_signal_emit_valist
  • #17 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #18 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #19 gtk_widget_send_focus_change
  • #20 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #21 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #22 g_closure_invoke
  • #23 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #24 g_signal_emit_valist
  • #25 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #26 g_closure_invoke
  • #27 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #28 g_signal_emit_valist
  • #29 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #30 gtk_widget_grab_focus
  • #31 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #32 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #33 g_closure_invoke
  • #34 ??
    from /usr/lib64/libgobject-2.0.so.0
  • #35 g_signal_emit_valist
  • #36 g_signal_emit
    from /usr/lib64/libgobject-2.0.so.0
  • #37 ??
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #38 gtk_propagate_event
  • #39 gtk_main_do_event
  • #40 ??
    from /usr/lib64/libgdk-x11-2.0.so.0
  • #41 g_main_context_dispatch
  • #42 ??
    from /usr/lib64/libglib-2.0.so.0
  • #43 g_main_loop_run
    from /usr/lib64/libglib-2.0.so.0
  • #44 app_run
  • #45 main

(script-fu:4697): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): error
Comment 1 Elle Stone 2017-12-10 19:32:03 UTC
Hmm, the specific (or a specific) action that triggers the crash is clicking on the icons in the upper right corner of the color picker readout(not sure which icon is the correct icon, I clicked on both of them) to get the color picker readout to detach itself from the upper right corner of the image. GIMP immediately crashes. 

Thinking back to a previous crash, it might also have crashed when trying to change the color space model in the left column from HSV to something else, again when the color picker readout is attached to the upper right corner of the image.
Comment 2 Elle Stone 2017-12-11 15:19:12 UTC
Unfortunately this isn't a crash that can be triggered by following a specified sequence of editing steps using a specific XCF file. Or at least I haven't yet figured out what that specific sequence/file might be. It doesn't happen very often. I did manage to trigger the crash twice in one editing session, but I don't know exactly what the sequence/conditions/etc might be.
Comment 3 Massimo 2017-12-15 13:39:58 UTC
Created attachment 365586 [details] [review]
do not compute device coords in inferior_ignore_mode

It is possible to reproduce this one also just with the mouse, provided 
that it is configured as an extended input device.
 
My reproduction conditions are:
Single window mode on X11;
rulers, scroll bars, menu, status bar hidden;
the grid is visible.

And then after two or three attempts to click 'Transform' or 'Reset'
on the on-canvas dialog for the unified tranform tool,
'Rotate' or 'Reset' for the rotate tool, or a dropdown list
in the color picker on canvas dialog, there is the crash:
 
The first rows of a stack trace are

> Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff72ebaed in gdk_input_translate_coordinates (gdkdev=gdkdev@entry=0xcea370, window=window@entry=0x3bb9a20
>     at gdkinput-x11.c:483
> 483         x_offset = - impl_window->input_window->root_x - priv->abs_x;
> #0  0x00007ffff72ebaed in gdk_input_translate_coordinates (gdkdev=gdkdev@entry=0xcea370, window=window@entry=0x3bb
>     at gdkinput-x11.c:483
> #1  0x00007ffff72ecf69 in IA__gdk_device_get_state (device=0xcea370, window=window@entry=0x3bb9a20, axes=axes@entr
>     at gdkinput-x11.c:952
> #2  0x00000000005b71c9 in gimp_device_info_get_device_coords (info=info@entry=0x10927d0, window=window@entry=0x3bb
>     at gimpdeviceinfo-coords.c:133
> #3  0x00000000005b74e1 in gimp_device_info_get_event_coords (info=info@entry=0x10927d0, window=0x3bb9a20, event=ev
>     at gimpdeviceinfo-coords.c:119
> #4  0x000000000055922f in gimp_display_shell_get_event_coords (shell=shell@entry=0x3abe060, event=event@entry=0x4b
>     at gimpdisplayshell-tool-events.c:1901
> #5  0x0000000000559a88 in gimp_display_shell_canvas_tool_events (canvas=canvas@entry=0x3ac1300, event=0x4b6e960, s
>     at gimpdisplayshell-tool-events.c:380
 
and impl_window->input_window is NULL.
   
A similar crash is obtained moving the pointer over the on-canvas
dialog with the stylus or the mouse and leaving it there and 
press/release a key (like using a shortcut to change the tool)


The attached patch avoids to compute and update coords info when the shell
has the flag inferior_ignore_mode TRUE (which corresponds to NONE 
input_extension_events) and the event is a FOCUS_CHANGE or KEY_PRESS or KEY_RELEASE,
those I observed leading to a crash.

With the patch the tablet behaves as with the rulers visible, that is not perfectly:

using a dropdown menu (units for the rotate tool, color representation for the color
picker), the focus goes to the canvas and on-canvas dialog controls do not respond, 
they show style changes hovering, but clicks are ignored until moving outside the 
on-canvas dialog.
Comment 4 Jehan 2017-12-16 22:15:26 UTC
I can't reproduce the crash at all even with a tablet, neither crashes nor warnings, nothing. I remember one day, not long ago, you told me one of the differences in your build which could trigger additional crashes. Could you tell me again, because I can't find your message on bugzilla?
Debug is already enabled of course, but I think you had something else on.

Or maybe could you propose some very detailed step-by-step for stupid people (me) because I tried with a tablet (and also with a mouse since you said it could work if it is enabled in Input Devices) set to "Screen" mode. I tried various on-canvas GUIs, hovering and hitting keys, clicking buttons and dropdown lists, etc. No crash at all.

This said I am tempted to just push your patch since you usually give us very good patches only. So if you are sure that's the right fix, just push. :-)
I am just a bit annoyed that I don't understand the details of what it does and why it fixes the crash.
What is the `inferior_ignore_mode` exactly?

Also while testing this, I discovered another bug which happens with on-canvas GUIs and tablets (bug 791689). Doesn't look related to the crash, but that's probably the same area of code.
Comment 5 Jehan 2017-12-16 22:16:17 UTC
Setting as blocker for 2.10 and NEW since it's a confirmed crash (by someone else).
Comment 6 Jehan 2017-12-16 22:29:02 UTC
Also how is your code related to the rulers being on or off? That's another thing which I don't understand.
Comment 7 Elle Stone 2017-12-17 00:58:15 UTC
If it helps, I just now applied Massimo's patch and rebuilt GIMP and will do some testing tomorrow. But the bug is very hit or miss on my system - today I managed to crash GIMP once when using the color picker (and just the mouse, not the brush at all, unlike previous crashes). But there weren't any crashes the preceeding day. FWIW, I've been using GIMP in Multi Window Mode, usually with the rulers visible.
Comment 8 Massimo 2017-12-17 07:18:38 UTC
(In reply to Elle Stone from comment #7)
> If it helps, I just now applied Massimo's patch and rebuilt GIMP and will do
> some testing tomorrow. But the bug is very hit or miss on my system - today
> I managed to crash GIMP once when using the color picker (and just the
> mouse, not the brush at all, unlike previous crashes). But there weren't any
> crashes the preceeding day. FWIW, I've been using GIMP in Multi Window Mode,
> usually with the rulers visible.

(In reply to Massimo from comment #3)
> Created attachment 365586 [details] [review] [review]
> do not compute device coords in inferior_ignore_mode
> 
> It is possible to reproduce this one also just with the mouse, provided 
> that it is configured as an extended input device.
>  
> My reproduction conditions are:
> Single window mode on X11;
> rulers, scroll bars, menu, status bar hidden;
> the grid is visible.
> 
...

Sorry, I wrote single window mode, but I meant multi window mode,
Elle's comment reminded me, the image window is just showing the image.

(In reply to Jehan from comment #4)
> I can't reproduce the crash at all even with a tablet, neither crashes nor
> warnings, nothing. I remember one day, not long ago, you told me one of the
> differences in your build which could trigger additional crashes. Could you
> tell me again, because I can't find your message on bugzilla?
> Debug is already enabled of course, but I think you had something else on.
> 
> Or maybe could you propose some very detailed step-by-step for stupid people
> (me) because I tried with a tablet (and also with a mouse since you said it
> could work if it is enabled in Input Devices) set to "Screen" mode. I tried
> various on-canvas GUIs, hovering and hitting keys, clicking buttons and
> dropdown lists, etc. No crash at all.

As I said above, try the same just in multi window mode.
Comment 9 Massimo 2017-12-17 07:33:22 UTC
(In reply to Jehan from comment #4)
...
> 
> This said I am tempted to just push your patch since you usually give us
> very good patches only. So if you are sure that's the right fix, just push.
> :-)

No don't push the patch as is. Consider that in 2.8 many overlay dialogs

https://git.gnome.org/browse/gimp/tree/app/tools/gimpimagemaptool.c?h=gimp-2-8#n304

were disabled because they were experimental, perhaps they must be
disabled also in gimp-2.9/10
...

> I am just a bit annoyed that I don't understand the details of what it does
> and why it fixes the crash.
> What is the `inferior_ignore_mode` exactly?

It is a flag that is set when the canvas shell disable extension events
introduced in bug #614441, I think that problem is broader than it was
initially observed

> 
> Also while testing this, I discovered another bug which happens with
> on-canvas GUIs and tablets (bug 791689). Doesn't look related to the crash,
> but that's probably the same area of code.

Yes that's What I described at the end of my previous comment
Comment 10 Massimo 2017-12-18 11:27:17 UTC
(In reply to Massimo from comment #8)
...
> > 
> > It is possible to reproduce this one also just with the mouse, provided 
> > that it is configured as an extended input device.
> >  
> > My reproduction conditions are:
> > Single window mode on X11;
> > rulers, scroll bars, menu, status bar hidden;
> > the grid is visible.
> > 

Just another observation, rulers visibility has to be disabled in 
preferences to produce the crash. Hiding them after the window has 
been created, it is possible to click on on-canvas controls without
crash.

so:

Multi window mode on X11
rulers, scroll bars, menu and status bar hidden in preferences
the grid is visible.
Comment 11 Massimo 2017-12-19 11:56:15 UTC
While testing possible solutions to this problem I found another way
to repeatably crash GIMP with the on-canvas color picker dialog visible
(this crash could be just a critical warning if glib is not configured
with --enable-debug):

In multi Window Mode
When the on-canvas color picker dialog is visible if I press <Ctrl>W

GIMP crashes and these are the first rows of a stack trace:

> Thread 1 "gimp-2.9" received signal SIGSEGV, Segmentation fault.
> 0x00000000006253ed in gimp_viewable_dialog_set_viewable (dialog=0x3ab1840, viewable=0x3ff3830, context=0xcdfa50) at gimpviewabledialog.c:277
> 277     g_return_if_fail (viewable == NULL || GIMP_IS_VIEWABLE (viewable));
> #0  0x00000000006253ed in gimp_viewable_dialog_set_viewable (dialog=0x3ab1840, viewable=0x3ff3830, context=0xcdfa50) at gimpviewabledialog.c:277
> #1  0x000000000056896a in gimp_tool_gui_update_viewable (gui=gui@entry=0x490d5b0) at gimptoolgui.c:886 
> #2  0x00000000005691e1 in gimp_tool_gui_create_dialog (gui=gui@entry=0x490d5b0, screen=screen@entry=0xce0940, monitor=monitor@entry=0) at gimptoolgui.c:806
> #3  0x0000000000569886 in gimp_tool_gui_set_overlay (gui=0x490d5b0, screen=0xce0940, monitor=0, overlay=0) at gimptoolgui.c:562
> #4  0x000000000056999f in gimp_tool_gui_canvas_resized (canvas=<optimized out>, unused=<optimized out>, gui=0x490d5b0) at gimptoolgui.c:934
> #5  0x00007ffff34ce745 in g_closure_invoke (closure=0x4900730, return_value=0x0, n_param_values=2, param_values=0x7fffffff9bf0, invocation_hint=0x7fffffff9
> #6  0x00007ffff34e1862 in signal_emit_unlocked_R (node=node@entry=0xd2d600, detail=detail@entry=0, instance=instance@entry=0x3ab6720, emission_return=emiss
Comment 12 Elle Stone 2017-12-21 21:50:02 UTC
Regarding bug 791797 and other bugs related to the various on-canvas dialogs, personally I dislike these on-canvas dialogs to the point of wanting to file a new bug report every time I click on the on-canvas dialog to make it an off-canvas dialog. 

In my own workflow there is almost never a time when it's more convenient to have the dialog be on-canvas. WRT to th color picker dialog, there is never, ever, ever a time when I want that dialog "on canvas" as it's always in the way of seeing the actual image, and also makes it difficult to color-pick under the on-canvas dialog - I might have actually filed a bug report on this topic wrt to the color picker dialog being on-canvas, but I just don't remember.

WRT to Comment 11 - I think I had the same crash terminal output a few days ago, but when I went to copy the output to this bug report, it was gone - apparently I closed geany without first saving the terminal output to disk.

If it turns out that disabling on-canvas dialogs is the easiest way to fix various crashes, from my perspective that sounds wonderful! though probably there are users who think the dialogs are great.

If the on-canvas dialogs are kept (or if they are removed, fixed and then re-added to GIMP), it would be very, very, very nice to have the option in Preferences to disable them either "all of them at once" or perhaps dialog by dialog.
Comment 13 Jehan 2017-12-21 21:56:51 UTC
(In reply to Elle Stone from comment #12)
> If the on-canvas dialogs are kept (or if they are removed, fixed and then
> re-added to GIMP), it would be very, very, very nice to have the option in
> Preferences to disable them either "all of them at once" or perhaps dialog
> by dialog.

I have opened bug 791859 to see how things are by 2.10 release. And whether we deactivate the on-canvas dialogs or not by 2.10, that would be worth a discussion for longer-term decision (probably on mailing list).
Comment 14 Michael Natterer 2018-01-04 18:06:36 UTC
This might be one of the bugs that Ell just fixed with bug 791689,
can you please try if it still happens?
Comment 15 Massimo 2018-01-05 05:58:20 UTC
(In reply to Michael Natterer from comment #14)
> This might be one of the bugs that Ell just fixed with bug 791689,
> can you please try if it still happens?

After disabling rulers in preferences restarting GIMP and clicking on
a on canvas dialog combo box (or button) with an extended input device
in multi window mode, GIMP still crashes.

I recalled it was already reported in bug #772005 and since for
a while rulers were worsening painting performance, many users
have them disabled and there are few possible duplicates:

bug #784480, bug #774715 bug #791621
Comment 16 Michael Natterer 2018-01-16 20:47:01 UTC
Also most likely the same as bug 784480

*** This bug has been marked as a duplicate of bug 784480 ***