bug#65193: 29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside read_socket_hook.

[YAMAMOTO Mitsuharu]

On Thu, 10 Aug 2023 22:03:31 +0900,
Po Lu wrote:
> 
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> 
> > To my understanding, the Lisp evaluator is not reentrant, and thus
> > Lisp evaluation inside read_socket_hook, which can be called from
> > fairly arbitrary places via unblock_input/maybe_quit, causes
> > hard-to-reproduce, spontaneous crashes.
> 
> Only if that Lisp is permitted to signal out of those arbitrary places,
> since we no longer call read_socket_hook directly from signal handlers.
> Mode line format evaluation catches all non-local exits, AFAIK.
>
> > That's really surprising.  I've once heard we shouldn't do that.  Is
> > that changed?
> 
> I think so, see above.

I quote an old post by Stefan Monnier (author of SYNC_INPUT) below:

> SYNC_INPUT doesn't make much difference here: indeed the code is not
> executed from the signal handler any more, but it's still handled at
> fairly arbitrary points in the code, many of whom do not allow execution
> of elisp code.  So w.r.t execution of elisp code from read_socket_hook,
> it's still a big no-no.
(https://lists.gnu.org/r/emacs-devel/2008-03/msg01090.html)

What made Lisp evaluation inside read_socket_hook possible since then?

At least it can cause some corruption/inconsistency unless every
unblock_input/maybe_quit takes account of potential GC (including
string compaction).  Long-standing code would originally be written
without such a consideration.  Is it already audited thoroughly?

> > My understanding is that GC can only be triggered by eval_sub or
> > Ffuncall calls (except explicit garbage_collect calls), but not by
> > Lisp object allocations, for example.  Avoiding Lisp evaluation inside
> > read_socket_hook also means avoiding GC inside read_socket_hook.
> 
> Hmm.  But given that we haven't avoided Lisp evaluation within
> read_socket_hook for some time now, that's still a moot point.

Since which version?

Probably the possibility of encountering the problem would be quite
low and even if it happens, it is really difficult to reproduce, let
alone to identify the root cause.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp