bug#60144: 30.0.50; PGTK Emacs crashes after signal

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: karl@karlotness.com,  60144@debbugs.gnu.org
> Date: Sun, 18 Dec 2022 14:22:04 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > You cannot require that from note_mouse_highlight, since it looks up
> > text and overlay properties, and those can signal an error if the
> > position is outside the valid/reachable range of buffer positions.
> 
> How about simply wrapping those calls in
> internal_catch_all/internal_condition_case?

This is too drastic, IMO: it would deprive us of valuable diagnostics
when note_mouse_highlight is called.  Like in this case, for example:
having the code signal an error allowed me to find a real bug.  We
were asking string_buffer_position_lim to check properties and
overlays for positions outside the BEGV..ZV interval, which can never
do anything useful, even if it isn't called in the PGTK context.  I've
now fixed that on the release branch.

In general, note_mouse_highlight should never examine invalid buffer
or string positions.  If it does, it's a bug that needs to be fixed.

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