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.

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.

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.

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.

Setting as blocker for 2.10 and NEW since it's a confirmed crash (by someone else).

Also how is your code related to the rulers being on or off? That's another thing which I don't understand.

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 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.

(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

(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.

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

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.

(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).

This might be one of the bugs that Ell just fixed with bug 791689,
can you please try if it still happens?

(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

Also most likely the same as bug 784480

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