GNU bug report logs - #65193
29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside read_socket_hook.

Previous Next

Full log

View this message in rfc822 format

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 65193 <at> debbugs.gnu.org
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

On Thu, 10 Aug 2023 17:26:00 +0900,
Po Lu wrote:
> 
> YAMAMOTO Mitsuharu <mituharu <at> 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 <at> math.s.chiba-u.ac.jp

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.