From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.bugs Subject: bug#65193: 29.1.50; SET_FRAME_ICONIFIED can cause Lisp evaluation inside read_socket_hook. Date: Fri, 11 Aug 2023 01:32:47 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <87pm3vs3qf.fsf@yahoo.com> <87zg2zqcbg.fsf@yahoo.com> Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32560"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?Q?Goj=C5=8D?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Cc: 65193@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 10 18:33:27 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qU8bH-0008G3-70 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Aug 2023 18:33:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qU8av-0004pw-LI; Thu, 10 Aug 2023 12:33:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qU8as-0004pm-AO for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 12:33:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qU8as-0006sZ-28 for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qU8ar-0001La-TJ for bug-gnu-emacs@gnu.org; Thu, 10 Aug 2023 12:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: YAMAMOTO Mitsuharu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Aug 2023 16:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65193 X-GNU-PR-Package: emacs Original-Received: via spool by 65193-submit@debbugs.gnu.org id=B65193.16916851745164 (code B ref 65193); Thu, 10 Aug 2023 16:33:01 +0000 Original-Received: (at 65193) by debbugs.gnu.org; 10 Aug 2023 16:32:54 +0000 Original-Received: from localhost ([127.0.0.1]:43924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU8aj-0001LD-IK for submit@debbugs.gnu.org; Thu, 10 Aug 2023 12:32:53 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:57484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qU8ag-0001L2-8v for 65193@debbugs.gnu.org; Thu, 10 Aug 2023 12:32:52 -0400 Original-Received: from mathent.math.s.chiba-u.ac.jp (mathent [192.168.32.5]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 46F1BF08EA; Fri, 11 Aug 2023 01:32:47 +0900 (JST) (envelope-from mituharu@math.s.chiba-u.ac.jp) In-Reply-To: <87zg2zqcbg.fsf@yahoo.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:267147 Archived-At: On Thu, 10 Aug 2023 22:03:31 +0900, Po Lu wrote: > > YAMAMOTO Mitsuharu 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