[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65193: 29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside
From: |
YAMAMOTO Mitsuharu |
Subject: |
bug#65193: 29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside read_socket_hook. |
Date: |
Thu, 10 Aug 2023 18:21:26 +0900 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
On Thu, 10 Aug 2023 17:26:00 +0900,
Po Lu wrote:
>
> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
> > SET_FRAME_ICONIFIED has a call to gui_consider_frame_title and it can
> > cause Lisp evaluation if icon-title-format or frame-title-format
> > contains (:eval FORM). This is problematic because
> > SET_FRAME_ICONIFIED can be called inside read_socket_hook.
> >
> > The call to gui_consider_frame_title was introduced by the following
> > change:
>
> What practical problems have resulted from this change?
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.
> There are already several situations under which Lisp can be called
> inside read_socket_hook.
That's really surprising. I've once heard we shouldn't do that. Is
that changed?
> And in principle, anything that performs GC can in turn call
> finalizers that subsequently run Lisp.
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.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp