bug#60144: 30.0.50; PGTK Emacs crashes after signal

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Do you understand why note_mouse_highlight was called in this
>> > scenario?  The backtrace seems strange: why should GTK care about our
>> > mouse highlight?
>> 
>> What happens here is that Emacs is reading input through GTK, either
>> inside xg_select or the read_socket_hook.  GTK then detects some mouse
>> motion and calls the motion event handler for the frame's widget, which
>> in turn calls note_mouse_movement.
>
> Why this fragile architecture of reading input events?  Calling
> functions of our Lisp machine from context where those functions
> cannot signal an error is very dangerous, and cannot work well in
> Emacs.  Why cannot we have the reads through GTK only deliver events
> to us, which we enqueue to our own event queue, and then we could
> process that queue in the safe context of the Lisp machine, as (AFAIK)
> we do on other platforms?

No, signalling there is equally unsafe on the other platforms, where
note_mouse_highlight is called from the same place(s): read_socket_hook,
event_handler_gdk, et cetera.  Just look at the callers of
x_note_mouse_movement in xterm.c, or [EmacsView mouseMoved:] in
nsterm.m.

But I see you already fixed the bug.  Thanks.