From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 17:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 75520@debbugs.gnu.org, eggert@cs.ucla.edu X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Paul Eggert Received: via spool by submit@debbugs.gnu.org id=B.173670172630532 (code B ref -1); Sun, 12 Jan 2025 17:09:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Jan 2025 17:08:46 +0000 Received: from localhost ([127.0.0.1]:48929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX1S9-0007wL-Hk for submit@debbugs.gnu.org; Sun, 12 Jan 2025 12:08:46 -0500 Received: from lists.gnu.org ([2001:470:142::17]:51326) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX1S6-0007vs-2K for submit@debbugs.gnu.org; Sun, 12 Jan 2025 12:08:43 -0500 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 1tX1Rx-00045i-Fm for bug-gnu-emacs@gnu.org; Sun, 12 Jan 2025 12:08:33 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX1Rv-00061z-4X for bug-gnu-emacs@gnu.org; Sun, 12 Jan 2025 12:08:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736701708; x=1736960908; bh=iyIjFuHyp3DhUS47tk5fk7iynxB4JfHSOI7gOhk0A6Y=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=ToKM3lNqOhKcm1JvHzOCdKwX89aZveAJLdwG4pc36JNgvmQmsnwlslr4YwlRBha8Z 0ixtaATu3fpogjpzoBzn4TFyTTuRS1XEq5z/PeYzyRRHeUT/OLI3tFzZSJ0xrVb7/c VC+hvfh/FE9rshP3gwirzwudU9TDt7FM9R5ydVgSIVS3idUuYuTuN1SSsjL/xLkOkF oF5qjaPZSeKPbEz4m/Do2hnN65HMBMQoCxc24VTZhcgn10Yhg95RFS9fyKQRsZjYV4 +HjgnufPuScuF//lSe5n+FcdTUZWhSx9F9GwW7MoqeIeFW79khXkR3fBkDHW2sC2X6 eJ11ulg5kVPyQ== Date: Sun, 12 Jan 2025 17:08:24 +0000 From: Pip Cet Message-ID: <87tta4ufi8.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 247c7da1f98445f2131ed4c09290d98c61351735 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.16; envelope-from=pipcet@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) When evaluated in -Q, this code: (funcall '(lambda () . #1=3D(t . #1#))) causes an unquittable infloop. IMHO, circular code isn't something we should support in any meaningful way: it's perfectly okay for it to have unexpected results, and throw any error message we can think of, or none, until I hit quit. However, I do think the loops should be quittable. The easiest way to ensure this is to move the maybe_quit call in eval_sub to the top of the function. I mentioned this problem to Paul Eggert and he provided the patch below, which also fixes two other cases I'd overlooked. There are similar issues with circular data: if Lisp code turns process-environment into a circular structure, for example, call_process will hang Emacs. If this should be fixed, please let me know so I can create a separate bug report and look for similar issues. >From a2015ba2f81c67b1a77054f0715ba3d643504a98 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 5 Jan 2025 17:30:18 -0800 Subject: [PATCH] Some maybe_quit fixes in eval.c * src/eval.c (skip_debugger): Use FOR_EACH_TAIL to avoid unquittable infloops. (eval_sub): Call maybe_quit earlier. (funcall_lambda): Use FOR_EACH_TAIL rather than calling maybe_quit each time through the loop. --- src/eval.c | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/src/eval.c b/src/eval.c index 3e899db4436..2fa60af90af 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2044,35 +2044,36 @@ wants_debugger (Lisp_Object list, Lisp_Object condi= tions) static bool skip_debugger (Lisp_Object conditions, Lisp_Object data) { - Lisp_Object tail; - bool first_string =3D 1; + Lisp_Object tail =3D Vdebug_ignored_errors; + bool first_string =3D true; Lisp_Object error_message; =20 error_message =3D Qnil; - for (tail =3D Vdebug_ignored_errors; CONSP (tail); tail =3D XCDR (tail)) + + FOR_EACH_TAIL (tail) { if (STRINGP (XCAR (tail))) =09{ =09 if (first_string) =09 { =09 error_message =3D Ferror_message_string (data); -=09 first_string =3D 0; +=09 first_string =3D false; =09 } =20 =09 if (fast_string_match (XCAR (tail), error_message) >=3D 0) -=09 return 1; +=09 return true; =09} else =09{ -=09 Lisp_Object contail; +=09 Lisp_Object contail =3D conditions; =20 -=09 for (contail =3D conditions; CONSP (contail); contail =3D XCDR (conta= il)) +=09 FOR_EACH_TAIL (contail) =09 if (EQ (XCAR (tail), XCAR (contail))) -=09 return 1; +=09 return true; =09} } =20 - return 0; + return false; } =20 /* Say whether SIGNAL is a `quit' error (or inherits from it). */ @@ -2470,6 +2471,11 @@ grow_specpdl_allocation (void) Lisp_Object eval_sub (Lisp_Object form) { + /* Call maybe_quit now, rather than just before calling maybe_gc, so + that callers like Fand, Fprogn and Fsetq need not call maybe_quit + each time through their loops. */ + maybe_quit (); + if (SYMBOLP (form)) { /* Look up its binding in the lexical environment. @@ -2483,8 +2489,6 @@ eval_sub (Lisp_Object form) if (!CONSP (form)) return form; =20 - maybe_quit (); - maybe_gc (); =20 if (++lisp_eval_depth > max_lisp_eval_depth) @@ -3262,10 +3266,8 @@ funcall_lambda (Lisp_Object fun, ptrdiff_t nargs, Li= sp_Object *arg_vector) bool optional =3D false; bool rest =3D false; bool previous_rest =3D false; - for (; CONSP (syms_left); syms_left =3D XCDR (syms_left)) + FOR_EACH_TAIL (syms_left) { - maybe_quit (); - Lisp_Object next =3D maybe_remove_pos_from_symbol (XCAR (syms_left))= ; if (!BARE_SYMBOL_P (next)) =09xsignal1 (Qinvalid_function, fun); --=20 2.45.2 From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 18:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier , Andrea Corallo Cc: 75520@debbugs.gnu.org, eggert@cs.ucla.edu Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.173670741830787 (code B ref 75520); Sun, 12 Jan 2025 18:44:02 +0000 Received: (at 75520) by debbugs.gnu.org; 12 Jan 2025 18:43:38 +0000 Received: from localhost ([127.0.0.1]:49091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX2vx-00080U-SM for submit@debbugs.gnu.org; Sun, 12 Jan 2025 13:43:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX2vv-00080D-0x for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 13:43:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX2vo-00087J-AR; Sun, 12 Jan 2025 13:43:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lezBFRGlKKVIknAXcLiFauJn6K5LV7fYd3YQLq7QLqE=; b=Rp5xl2HzEXdNfB2o/Sff vLgSyrMNI+Oh0AwYUE+LFe+rM+ieR71gTT9wXFSK9QxzCpjL/D1i8kDpizlxvPFlcFl23WRIUS2iQ C4mIBIDAS44L9asqF+mlo1r6Q04UdjdRJW/mr8YRmpVq+NTkAwkrzfo1qOsBlabmdUoWafjGymUHQ ksB0AfI1ldSvZL0pjxHHZ0WaXCBB0UAEybOS+jwmBa9D4qzqxcwzmdvt7L1AGSYWQUR75tu0bC9K3 VohUvJIdhQABdgC+a0OkC3eWyx84x+cp+bmfopqu9aNYDoFT9M6PW8i9jpys9/vPyeYd9OESoAqpL W8FvF/BM2ukAiw==; Date: Sun, 12 Jan 2025 20:43:25 +0200 Message-Id: <86r057x48i.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87tta4ufi8.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) References: <87tta4ufi8.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 12 Jan 2025 17:08:24 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > When evaluated in -Q, this code: > > (funcall '(lambda () . #1=(t . #1#))) > > causes an unquittable infloop. > > IMHO, circular code isn't something we should support in any meaningful > way: it's perfectly okay for it to have unexpected results, and throw > any error message we can think of, or none, until I hit quit. However, > I do think the loops should be quittable. > > The easiest way to ensure this is to move the maybe_quit call in > eval_sub to the top of the function. I mentioned this problem to Paul > Eggert and he provided the patch below, which also fixes two other cases > I'd overlooked. > > There are similar issues with circular data: if Lisp code turns > process-environment into a circular structure, for example, call_process > will hang Emacs. If this should be fixed, please let me know so I can > create a separate bug report and look for similar issues. Thanks, let's hear what others (CC'ed) think about this. > >From a2015ba2f81c67b1a77054f0715ba3d643504a98 Mon Sep 17 00:00:00 2001 > From: Paul Eggert > Date: Sun, 5 Jan 2025 17:30:18 -0800 > Subject: [PATCH] Some maybe_quit fixes in eval.c > > * src/eval.c (skip_debugger): > Use FOR_EACH_TAIL to avoid unquittable infloops. > (eval_sub): Call maybe_quit earlier. > (funcall_lambda): Use FOR_EACH_TAIL rather than calling > maybe_quit each time through the loop. > --- > src/eval.c | 30 ++++++++++++++++-------------- > 1 file changed, 16 insertions(+), 14 deletions(-) > > diff --git a/src/eval.c b/src/eval.c > index 3e899db4436..2fa60af90af 100644 > --- a/src/eval.c > +++ b/src/eval.c > @@ -2044,35 +2044,36 @@ wants_debugger (Lisp_Object list, Lisp_Object conditions) > static bool > skip_debugger (Lisp_Object conditions, Lisp_Object data) > { > - Lisp_Object tail; > - bool first_string = 1; > + Lisp_Object tail = Vdebug_ignored_errors; > + bool first_string = true; > Lisp_Object error_message; > > error_message = Qnil; > - for (tail = Vdebug_ignored_errors; CONSP (tail); tail = XCDR (tail)) > + > + FOR_EACH_TAIL (tail) > { > if (STRINGP (XCAR (tail))) > { > if (first_string) > { > error_message = Ferror_message_string (data); > - first_string = 0; > + first_string = false; > } > > if (fast_string_match (XCAR (tail), error_message) >= 0) > - return 1; > + return true; > } > else > { > - Lisp_Object contail; > + Lisp_Object contail = conditions; > > - for (contail = conditions; CONSP (contail); contail = XCDR (contail)) > + FOR_EACH_TAIL (contail) > if (EQ (XCAR (tail), XCAR (contail))) > - return 1; > + return true; > } > } > > - return 0; > + return false; > } > > /* Say whether SIGNAL is a `quit' error (or inherits from it). */ > @@ -2470,6 +2471,11 @@ grow_specpdl_allocation (void) > Lisp_Object > eval_sub (Lisp_Object form) > { > + /* Call maybe_quit now, rather than just before calling maybe_gc, so > + that callers like Fand, Fprogn and Fsetq need not call maybe_quit > + each time through their loops. */ > + maybe_quit (); > + > if (SYMBOLP (form)) > { > /* Look up its binding in the lexical environment. > @@ -2483,8 +2489,6 @@ eval_sub (Lisp_Object form) > if (!CONSP (form)) > return form; > > - maybe_quit (); > - > maybe_gc (); > > if (++lisp_eval_depth > max_lisp_eval_depth) > @@ -3262,10 +3266,8 @@ funcall_lambda (Lisp_Object fun, ptrdiff_t nargs, Lisp_Object *arg_vector) > bool optional = false; > bool rest = false; > bool previous_rest = false; > - for (; CONSP (syms_left); syms_left = XCDR (syms_left)) > + FOR_EACH_TAIL (syms_left) > { > - maybe_quit (); > - > Lisp_Object next = maybe_remove_pos_from_symbol (XCAR (syms_left)); > if (!BARE_SYMBOL_P (next)) > xsignal1 (Qinvalid_function, fun); > -- > 2.45.2 > > > > > > From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 19:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Pip Cet , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier , Andrea Corallo Cc: 75520@debbugs.gnu.org Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17367091914702 (code B ref 75520); Sun, 12 Jan 2025 19:14:01 +0000 Received: (at 75520) by debbugs.gnu.org; 12 Jan 2025 19:13:11 +0000 Received: from localhost ([127.0.0.1]:49139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX3OX-0001Di-2G for submit@debbugs.gnu.org; Sun, 12 Jan 2025 14:13:11 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:48570) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX3OU-0001DA-Rn for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 14:13:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 77DC43C123873; Sun, 12 Jan 2025 11:13:00 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id QcureFiH_uqE; Sun, 12 Jan 2025 11:13:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 383FD3C123875; Sun, 12 Jan 2025 11:13:00 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 383FD3C123875 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1736709180; bh=k2Z09Z2uu8yGuGR/s/smubWDwhT3e+YVPY0U4cRx4UA=; h=Message-ID:Date:MIME-Version:To:From; b=nb/t+fqpBai+MnSGAMJ8iHjWCGly0etnRfvuEzj8IuRnCQlIxRn0BL/71RMU4mT0s 0sD7pPPORxeS+G1PuT2qHb7sgbg3VzpaHNyZu9bpxqajilUOuo1dubiauAbsE+2KqB gUo4L1S3C1UVvU5LTLmsMTdi3+V+6HWDJ3jxkZmE45umXtwVM4kp+ol01AR9Y3Zaf7 zV48Cs1cCVlc3CltQ42TvZzNM2LNH8Wi9QC8wTtJ9mzkKvjZASxMaZFpaITxNhcM55 lQuTmyghX0ejOv+1lDwuQUEfTPpqqDewpq90iex4YSF5rS+MRo14EJiYvv4ACxZ3L1 cdgOD+fMBjlfg== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id s5hBGLq0kWxo; Sun, 12 Jan 2025 11:13:00 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 16BD63C123873; Sun, 12 Jan 2025 11:13:00 -0800 (PST) Message-ID: <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> Date: Sun, 12 Jan 2025 11:12:59 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86r057x48i.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-01-12 10:43, Eli Zaretskii wrote: >> Date: Sun, 12 Jan 2025 17:08:24 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> There are similar issues with circular data: if Lisp code turns >> process-environment into a circular structure, for example, call_process >> will hang Emacs. If this should be fixed, please let me know so I can >> create a separate bug report and look for similar issues. > > Thanks, let's hear what others (CC'ed) think about this. I'd like the process-environment bug fixed too. The bug should be easy to fix, and an unquittable Emacs is a real pain for all concerned. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: 75520@debbugs.gnu.org, mattiase@acm.org, pipcet@protonmail.com, acorallo@gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17367101438046 (code B ref 75520); Sun, 12 Jan 2025 19:30:02 +0000 Received: (at 75520) by debbugs.gnu.org; 12 Jan 2025 19:29:03 +0000 Received: from localhost ([127.0.0.1]:49164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX3dv-00025i-6D for submit@debbugs.gnu.org; Sun, 12 Jan 2025 14:29:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49402) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX3ds-000257-NR for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 14:29:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX3dm-0004ez-DT; Sun, 12 Jan 2025 14:28:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9fSmIF9v9Rq+OrmjfDtKXOXfQI21zW1yyEXrTHVdAEk=; b=ABRj61O0d8hD RXf/Xd8MshM58xoCIQC0jBujKqmoK7PcofqxCRPt0SN+p9PATTPfm79ju1PQdLCivM7o20uxG0yWK vWr7m0uMS63bKCrCPZQ5zDN5fPJBJGb2gg+rb4BFt7epgmSW+MFbNtF6vH7Q/pm08IZMgU9PFT3z6 hU8R5PDbbXrwRxmqp7Mp1q2U9KMLOJ7LADYMacC1tUrIdwKRn9AY8SZ0Vl8PFczd07HamrMeTpeSs xVofBEDhZvUKfDVlXIAfLJIpaHPVNDOeD89iD0mYYKh9+R29eghSiqwJ96HJKxIR9kvCjyNa1S4QS YqyI6ASLMWljFXf03KWrhQ==; Date: Sun, 12 Jan 2025 21:28:51 +0200 Message-Id: <86h663x24s.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> (message from Paul Eggert on Sun, 12 Jan 2025 11:12:59 -0800) References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 12 Jan 2025 11:12:59 -0800 > Cc: 75520@debbugs.gnu.org > From: Paul Eggert > > On 2025-01-12 10:43, Eli Zaretskii wrote: > >> Date: Sun, 12 Jan 2025 17:08:24 +0000 > >> From: Pip Cet via "Bug reports for GNU Emacs, > > >> There are similar issues with circular data: if Lisp code turns > >> process-environment into a circular structure, for example, call_process > >> will hang Emacs. If this should be fixed, please let me know so I can > >> create a separate bug report and look for similar issues. > > > > Thanks, let's hear what others (CC'ed) think about this. > > I'd like the process-environment bug fixed too. Which bug is that? Does it have a number? From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 20:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 75520@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Pip Cet , Andrea Corallo , eggert@cs.ucla.edu Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.173671353121086 (code B ref 75520); Sun, 12 Jan 2025 20:26:02 +0000 Received: (at 75520) by debbugs.gnu.org; 12 Jan 2025 20:25:31 +0000 Received: from localhost ([127.0.0.1]:49255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX4WZ-0005U0-Hx for submit@debbugs.gnu.org; Sun, 12 Jan 2025 15:25:31 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57298) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX4WX-0005Ti-CN for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 15:25:29 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C963780833; Sun, 12 Jan 2025 15:25:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1736713522; bh=45Cs9YihYFRSA1+kp2mrM72QrVb1/IzC7bP0JTwMGzU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fWYMeBGUK8P52niDP3syG6uYKgNTPfZF/I/FV8elOoTbtw5/dL1FFkRID8r7RaO3H hqF+n6tLk4bCBpUK0sl7mJV1ugFg88BF4h1Tr3LdzLDHVy81r2sKPojAa6HRFu512c ZV6o6IdftuwnikUmfT9LA1gm7RMOCcEmgoyv8b8E0fZVJt0Ujy5ssjvDbp8A2f0Lyd pYq+93z2XfWsPO+kQ625yXwhklzo/0u6pAri+uvtoxRtwZNvJVoQHYjszlr210+Mjp jF8FkfJIKYCtZ7PDiFCg8XKZ09sWZNGr1clV/rGZP8IqIgUcwmMZNz9ZJxWWxJbenm 27+IsE8JCwkNw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0FF0480784; Sun, 12 Jan 2025 15:25:22 -0500 (EST) Received: from alfajor (104-195-232-86.cpe.teksavvy.com [104.195.232.86]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BFB3012069F; Sun, 12 Jan 2025 15:25:21 -0500 (EST) From: Stefan Monnier In-Reply-To: <86r057x48i.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Jan 2025 20:43:25 +0200") Message-ID: References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> Date: Sun, 12 Jan 2025 15:25:21 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.032 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> There are similar issues with circular data: if Lisp code turns >> process-environment into a circular structure, for example, call_process >> will hang Emacs. If this should be fixed, please let me know so I can >> create a separate bug report and look for similar issues. > Thanks, let's hear what others (CC'ed) think about this. I'm in favor of fixing all those unquittable inf-loops, except maybe when there a very strong reason not to, which I fail to see here. Stefan From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Jan 2025 21:47:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Paul Eggert Cc: 75520@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , Andrea Corallo , Stefan Monnier Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17367184202356 (code B ref 75520); Sun, 12 Jan 2025 21:47:03 +0000 Received: (at 75520) by debbugs.gnu.org; 12 Jan 2025 21:47:00 +0000 Received: from localhost ([127.0.0.1]:49340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX5nQ-0000bu-2X for submit@debbugs.gnu.org; Sun, 12 Jan 2025 16:47:00 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:47079) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX5nN-0000bf-Sk for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 16:46:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736718411; x=1736977611; bh=zURtQDnwmb1VrR2Kjy+VCL8PrzGvo+ChunuRNrYhpfU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=yUutPPiy2Ic1BE/oTtWB8z1VLASvEn3oLTEmTtNNLPXHvi/0NBQ6V6KOCkunpMIAA DVWwFt/5lTSNMgX0w1MCCqIhDI1gguMczGrzTIdR3YMpODVA93h8ckpP7TUqWSPk4l Iy7QEMkj2SHpY0/rSsD6cC6aWURg4rTSctmhbGauijkpnr0U5lyT4c/yVG93Y8XR9q UWay8CznxM0tMS9z0xAlxxvqW6o3vyMJlNwGx8Gbpw2w0QJ8djI4UAjzNYlEJ2ksH5 eCGNN4K1csDDbNm9tB81MHZ5W1236N+stokTs+W+E4JxxXHrlAzEeyVv8tCC2hKKS3 07OYonkeOPuGA== Date: Sun, 12 Jan 2025 21:46:46 +0000 From: Pip Cet Message-ID: <87zfjvu2mb.fsf@protonmail.com> In-Reply-To: <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8559599a696867d8340b80c57b20f6131e291b66 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Paul Eggert" writes: > On 2025-01-12 10:43, Eli Zaretskii wrote: >>> Date: Sun, 12 Jan 2025 17:08:24 +0000 >>> From: Pip Cet via "Bug reports for GNU Emacs, > >>> There are similar issues with circular data: if Lisp code turns >>> process-environment into a circular structure, for example, call_proces= s >>> will hang Emacs. If this should be fixed, please let me know so I can >>> create a separate bug report and look for similar issues. >> >> Thanks, let's hear what others (CC'ed) think about this. > > I'd like the process-environment bug fixed too. The bug should be easy > to fix, and an unquittable Emacs is a real pain for all concerned. This seems to be a common problem. I did a quick git grep 'while.*CONSP': definitely broken: debug-on-error, debug-ignored-errors, unread-command-events, timer-list, the argument to Fkeymap_prompt possibly broken: the 'error-conditions symbol property, image specs (gtkutil.c checks valid_image_p, then runs Lisp, which might modify the spec), buffer-undo-list (truncate_undo_list; please ensure ditty is preserved), other functions in keymap.c. git grep 'for.*CONSP' also returns many hits, which I haven't looked at (it's also common to have the "for" keyword on a different line than the CONSP, of course). Pip From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jan 2025 02:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 75520@debbugs.gnu.org, mattiase@acm.org, pipcet@protonmail.com, acorallo@gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17367369711779 (code B ref 75520); Mon, 13 Jan 2025 02:57:01 +0000 Received: (at 75520) by debbugs.gnu.org; 13 Jan 2025 02:56:11 +0000 Received: from localhost ([127.0.0.1]:49687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXAcd-0000Sd-FN for submit@debbugs.gnu.org; Sun, 12 Jan 2025 21:56:11 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:38666) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXAcZ-0000SI-OJ for 75520@debbugs.gnu.org; Sun, 12 Jan 2025 21:56:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C6E0B3C011BDD; Sun, 12 Jan 2025 18:56:00 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id G7CNLSiJRlXc; Sun, 12 Jan 2025 18:56:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 895DA3C0275C3; Sun, 12 Jan 2025 18:56:00 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 895DA3C0275C3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1736736960; bh=EE+RuN6M2/Z8PYvV/6Iwooc1CEkF+afy7LVHT4Bejf4=; h=Message-ID:Date:MIME-Version:To:From; b=Zz2WxUdwQJbIQhRcaoilqpSuMbpX3eW8+nNK4HYKFfyxnWGP2kbJvIBLLaerCHRr/ uSQ41ULLXOLDG6h+yLJC9d3bcTCIzkH6Vc26zdUU2xf8dtt9Vp4DjNBmijCO3SxBAB R3/lpJcg5jb0YFwopnUD6Ej6kDOf8JoK89FYnyDRs0vgvUhlfBc33egD0uAY2haqoi 43WtMAF0yt2MjVTI96YbQBLR4G7/f+dETtuNDM5mwW3CalEgNVE8+K0Nn2CsD9t7Q0 vwpTzJWEb6PPmCP6xqYxPDXVypN8T/6khmpocV58FSjEwxKDM5KJhvM6EDiM8k6RD6 mu835j2v8RJlA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id gXHLsyAQi4wd; Sun, 12 Jan 2025 18:56:00 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 652133C011BDD; Sun, 12 Jan 2025 18:56:00 -0800 (PST) Message-ID: Date: Sun, 12 Jan 2025 18:56:00 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <86h663x24s.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86h663x24s.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-01-12 11:28, Eli Zaretskii wrote: >> I'd like the process-environment bug fixed too. > Which bug is that? Does it have a number? Yes, it's the bug number 75520 that we're currently discussing. Look for "process-environment" in the original bug report. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Jan 2025 05:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 75520@debbugs.gnu.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii , Andrea Corallo , Stefan Monnier Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.173674788532271 (code B ref 75520); Mon, 13 Jan 2025 05:59:02 +0000 Received: (at 75520) by debbugs.gnu.org; 13 Jan 2025 05:58:05 +0000 Received: from localhost ([127.0.0.1]:49866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXDSf-0008OR-00 for submit@debbugs.gnu.org; Mon, 13 Jan 2025 00:58:05 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:40826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXDSc-0008Nu-BY for 75520@debbugs.gnu.org; Mon, 13 Jan 2025 00:58:02 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 7FA013C011BDD; Sun, 12 Jan 2025 21:57:56 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id tJrVyagUv-1h; Sun, 12 Jan 2025 21:57:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 370F63C03E9DE; Sun, 12 Jan 2025 21:57:56 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 370F63C03E9DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1736747876; bh=ucenpFlM2HMDsK3bmzUhgJg9IJ9Bi3diQHBH+XHABkI=; h=Message-ID:Date:MIME-Version:To:From; b=n5tx/2JbmVJ37Os4f4GR5g8RhVy7YXE7htgIJJYLyDiyQnOFaAoc1HNv2kXVJM0O1 NBT4DVvXXZNhHgX4uTJHxZbGbQX1hHzdJMYj0vJhabo5Vj/vz3nPQwx0ndd6XYjDQM xJuDNN6OdFC+4ephnfEJ7XtuJRBA2sZ58aHN0mXdIE6anliotCmPmg6+cwZQ2TcGd/ Pd5Ve39ffGL3RhxBtfmLjdbIGaS5NWpmhiTKq3BhaT1slt7aVPbEOKpMLmYUn5Qc9l +SzS0zR070zy7ZfifBnJb/2TZJbq9t2mMI6J02ecm3U6mOMRldYzjkS9Gm5CphQTDg APLo1zkVhHEbA== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id LXGY1nTBST4d; Sun, 12 Jan 2025 21:57:56 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 12E003C011BDD; Sun, 12 Jan 2025 21:57:56 -0800 (PST) Message-ID: <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> Date: Sun, 12 Jan 2025 21:57:55 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87zfjvu2mb.fsf@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-01-12 13:46, Pip Cet wrote: > This seems to be a common problem. I did a quick git grep > 'while.*CONSP': Yes, I did something similar in 2017; see, for example, commit 14dd9101ec4838f75addf25bf6b06ef33f8a7e97, which fixes 'length', 'member', 'memq', etc. I don't remember how carefully I audited the code for the problem way back then. Either I missed several potential issues, or the code has changed since then, or both. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 16:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@protonmail.com, Paul Eggert Cc: 75520@debbugs.gnu.org, mattiase@acm.org, acorallo@gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17368724115712 (code B ref 75520); Tue, 14 Jan 2025 16:34:02 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 16:33:31 +0000 Received: from localhost ([127.0.0.1]:55442 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXjr8-0001U4-Us for submit@debbugs.gnu.org; Tue, 14 Jan 2025 11:33:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51714) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXjr5-0001Tn-3b for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 11:33:29 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXjqx-0007Qg-MI; Tue, 14 Jan 2025 11:33:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/q6XeVhTsRTPFyhmK1ZfpTTDlKk1YP3Xc6QWD18AflA=; b=eTwbV43Dolq43D1SYv4q cHgunY9yokZuMUn5fhRsv2KBI9hhUkd/LaYcRYlGN0xc4jpWhK7iqWZBIOxP4i5QQLCT6SRpwt+cB DEvCde55JrN7o5ZRy3rGJq/I1kQ+Vl0XuKmU/+zSKfj9R3PSghAngoGi51nk+KkyJleLLqMBlQ/EO ea9JK0tNj5gadmuPuhE2sJLa8GjJazbZn07mSX/m+swUL64B5gsEgl8FE0D8wJ132BdPOoD2GeRpB WTwlg2Br5H0ONl9k0VRH9kXq9eJQac1RKSa8B+jEZyCa2+5/a/Tw7+EIEZpp0wnG0aog97VfTzVb7 iTmML1Z4LazdRw==; Date: Tue, 14 Jan 2025 18:32:40 +0200 Message-Id: <86bjw9tkyf.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> (message from Paul Eggert on Sun, 12 Jan 2025 21:57:55 -0800) References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 12 Jan 2025 21:57:55 -0800 > Cc: Eli Zaretskii , Mattias Engdegård > , Stefan Monnier , > Andrea Corallo , 75520@debbugs.gnu.org > From: Paul Eggert > > On 2025-01-12 13:46, Pip Cet wrote: > > This seems to be a common problem. I did a quick git grep > > 'while.*CONSP': > > Yes, I did something similar in 2017; see, for example, commit > 14dd9101ec4838f75addf25bf6b06ef33f8a7e97, which fixes 'length', > 'member', 'memq', etc. I don't remember how carefully I audited the code > for the problem way back then. Either I missed several potential issues, > or the code has changed since then, or both. Seems like we have a consensus here that this should be fixed. But can we please have at least one test for every place where we fix this kind of bug? Thanks. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, mattiase@acm.org, Paul Eggert , 75520@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.173688037032552 (code B ref 75520); Tue, 14 Jan 2025 18:47:02 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 18:46:10 +0000 Received: from localhost ([127.0.0.1]:55721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXlvV-0008Sw-Qx for submit@debbugs.gnu.org; Tue, 14 Jan 2025 13:46:10 -0500 Received: from mail-10630.protonmail.ch ([79.135.106.30]:14855) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXlvP-0008S3-R3 for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 13:46:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736880356; x=1737139556; bh=Dz6pFsp3+vMGyfJBjm/Y1gSXzxMS3CHW4ruJEuf6Wqs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=es1eDXjgi7YVT5xeS3Mr50f6P4KReRQDMZZA+hWcKC10OjEh2upNR36dG/BNFAhNz 9A+FumM3PVEqyfxe9VOoYgWAC15HNOo2KJhZJC4i+J9lTGyWTaR2Ubc9OrR4rbK0qQ 6cwfgWOhoNK0SB6WzX9p2J9eX2IBaMXCmPbcGkKtPxHwrkr6pu5LGG5Lxb2JcD1T14 2ugY6YXx1YNedCdu6rGmWKNQ8ZG4sFlBGIW51RGUcJ5SRtTlKOyTcXAS3WAGfV9S+O qnsQCZ4lsimTdGsT0vXyLQn1bX9txYDCQdnxybbLrrRvfC652cx7P/fqu0nmDS3aQT lmA3iLC+NJj9A== Date: Tue, 14 Jan 2025 18:45:51 +0000 From: Pip Cet Message-ID: <87tta1p73h.fsf@protonmail.com> In-Reply-To: <86bjw9tkyf.fsf@gnu.org> References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 181a2013c2bdb8e2ff05d5286c77ac308cd91451 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Sun, 12 Jan 2025 21:57:55 -0800 >> Cc: Eli Zaretskii , Mattias Engdeg=C3=A5rd >> , Stefan Monnier , >> Andrea Corallo , 75520@debbugs.gnu.org >> From: Paul Eggert >> >> On 2025-01-12 13:46, Pip Cet wrote: >> > This seems to be a common problem. I did a quick git grep >> > 'while.*CONSP': >> >> Yes, I did something similar in 2017; see, for example, commit >> 14dd9101ec4838f75addf25bf6b06ef33f8a7e97, which fixes 'length', >> 'member', 'memq', etc. I don't remember how carefully I audited the code >> for the problem way back then. Either I missed several potential issues, >> or the code has changed since then, or both. > > Seems like we have a consensus here that this should be fixed. I agree, but it's a significant task: My git grep caught ~8 bugs, but covered only 22% of cases (at best), so I'd naively expect at least 20 bugs, and fixing them is usually simple but occasionally tedious (because one might forget to include an additional check, for example, as I did when I accidentally removed a STRINGP (XCAR (tem)) on scratch/igc). (I don't know what happened to coccinelle; it used to be good at this kind of task, but I'm not sure it's still being developed or extended in the appropriate ways). My preference would be to use FOR_EACH_TAIL where we can, and to retain that macro's quitting behavior: while the comment claims there is no reason to quit in FOR_EACH_TAIL because Emacs doesn't support "very long" lists, I believe that statement to be inaccurate for the MPS branch. I can easily create a 100-million-entry list on the master branch, too; it takes a few seconds to create (and a few more to collect). That would mean: 1. find likely infloops 2. prove that the infloop actually is reachable 3. check each loop for extra conditions 4. ensure that the loop is a good place to quit 5. use FOR_EACH_TAIL 6. write a test for each case I'm volunteering to do 1, 3, 4, 5. I think (2) is a waste of time, to be honest: if it looks like a bug and there isn't a clear comment indicating that it's not one, it should be fixed. (6) is very hard, if we actually want the test to fail (i.e. infloop) reliably for unfixed Emacs versions. (I also think a blind belief that more tests are better is unwarranted, but that's a project decision; since we have decided to test exhaustively, if not as exhaustively as possible, I'll do that). If (4) isn't possible, we'll have to put an Flength call somewhere further up the call chain. As for (2), consider, for example, the Qerror_conditions property of a symbol. skip_debugger contains an unprotected loop iterating through this property (this is the inner loop; the outer loop, iterating over Vdebug_ignored_errors, definitely can cause an infloop); if we ever reach that code, we'll infloop. I tried setting the Qerror_conditions property to a circular list, but it didn't infloop. Do I now go and try to prove conclusively that every code path that reaches skip_debugger is actually safe? If so, do I add comments to every code paths to ensure that it will remain safe? I think the effort to do so is disproportionate: let's just use FOR_EACH_TAIL_SAFE there, even if there is a possibility that it might not be required for correctness. > But can we please have at least one test for every place where we fix > this kind of bug? Assuming you mean a test case that reliably infloops unfixed Emacs: probably not. If the requirement is simply to make some variable circular and call code which might refer to it, on the off chance that that code would infloop once in a while, maybe. And what if we can't find such a test? I'm pretty sure find_font_encoding isn't unused, and it will infloop if Vfont_encoding_alist is circular and we don't want to return one of its elements, but how do I trigger it? Even if I managed to trigger it on my system (no luck so far), would that do anything on Windows, with its totally different font handling code? Wouldn't it depend on which fonts are installed? Pip From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 19:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 75520@debbugs.gnu.org, mattiase@acm.org, Eli Zaretskii , acorallo@gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17368814583608 (code B ref 75520); Tue, 14 Jan 2025 19:05:01 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 19:04:18 +0000 Received: from localhost ([127.0.0.1]:55741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXmD4-0000w8-05 for submit@debbugs.gnu.org; Tue, 14 Jan 2025 14:04:18 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:37114) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXmCz-0000vo-Vu for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 14:04:15 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 936743C00FAB3; Tue, 14 Jan 2025 11:04:07 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id JSLHLHJG2p-q; Tue, 14 Jan 2025 11:04:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 5002A3C0275C1; Tue, 14 Jan 2025 11:04:07 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 5002A3C0275C1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1736881447; bh=0By4hBKpIAPwg/Kvt42n4SCBy+dDPkxWt6ftGO/emyY=; h=Message-ID:Date:MIME-Version:To:From; b=IIItTqaY5yUbDRkpqWF6mN4M1etTvBZmaHu8XcPgtEJuHQBV/pXqQI+8J9NxEzKN1 69udTqO1nGMXtIR4icDMrJhnbt7upt6pmSF5gCQTgfc6z35NYDJMXfTSb8d6b18ygX mp17otFeMHdHRpizBANeuqWdSGYE+qKv1pQV+Im246dZJo7h/QpOCTi4pCBHSqbl27 ViqLSsSKIbSShksOfufetVCXHjGWfbH2jVuUSsaAtiQgvCSsesw0UQuAc9w557ePhN yb+P6JrxWBwq/TYhMvQ85GI+5NkIpzsNk/EKpMypv7jrhR4T43O7jKXmNrlgzSjqXR 1lvjxXsrZhFNQ== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id mT_Z_5RG23yX; Tue, 14 Jan 2025 11:04:07 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 276173C00FAB3; Tue, 14 Jan 2025 11:04:07 -0800 (PST) Message-ID: Date: Tue, 14 Jan 2025 11:04:06 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <87tta1p73h.fsf@protonmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 2025-01-14 10:45, Pip Cet wrote: > And what if we can't find such a test? I'm with you. Any requirement that we implement a test case for every such bug we fix would immediately turn on a light bulb in my head saying "don't report or fix the bug". It's OK if someone else wants to do it, but my volunteer time is too limited to do that kind of busywork. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 21:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: acorallo@gnu.org, mattiase@acm.org, eggert@cs.ucla.edu, 75520@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.173688922827870 (code B ref 75520); Tue, 14 Jan 2025 21:14:01 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 21:13:48 +0000 Received: from localhost ([127.0.0.1]:55968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXoEO-0007FS-7t for submit@debbugs.gnu.org; Tue, 14 Jan 2025 16:13:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43086) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXoEL-0007F9-4P for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 16:13:45 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXoEA-0006iz-QK; Tue, 14 Jan 2025 16:13:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cP3/a9FBGjtnyd+5fgxeRRV2Q3TrX5l+Xhw5jO7z8Gs=; b=IQ+T3GHtq3EY m/eNQ7d+DA/PbAG3rajIPgk4nu+JEafh+VF8ave+la83Aq/E9vXRNGtFE5Hd8WFY95G5NnCA9qDHx xw0UHkKS4ctYcGH0MhLx5jP2LNFB59YGUJgQmRzJIppjTXQzCgiz55KlrjUeI7dVWz7WSsFRmgSnK 59RQgR+ZVkXxyNL9CnOfM/Z9WYB28c7M5DgGzqD+9FbsAQGe5P7/N32N+6gPcU37wSAtnMDap1h43 l0dppYWPbrpxn4LsHuGE6YqqCDEKvH6OL3usHz0D/JGMlw0UqQwpBY8SS0SJdfgeNGU8dWNkIvpYs klBblT1i3zzfMumn4Hr5Ww==; Date: Tue, 14 Jan 2025 23:13:27 +0200 Message-Id: <8634hlt7yg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87tta1p73h.fsf@protonmail.com> (message from Pip Cet on Tue, 14 Jan 2025 18:45:51 +0000) References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 14 Jan 2025 18:45:51 +0000 > From: Pip Cet > Cc: Paul Eggert , mattiase@acm.org, monnier@iro.umontreal.ca, acorallo@gnu.org, 75520@debbugs.gnu.org > > > Seems like we have a consensus here that this should be fixed. > > I agree, but it's a significant task: My git grep caught ~8 bugs, but > covered only 22% of cases (at best), so I'd naively expect at least 20 > bugs, and fixing them is usually simple but occasionally tedious > (because one might forget to include an additional check, for example, > as I did when I accidentally removed a STRINGP (XCAR (tem)) on > scratch/igc). We can fix only the most painful ones. We don't need to make sure none remain, if it isn't easy. > > But can we please have at least one test for every place where we fix > > this kind of bug? > > Assuming you mean a test case that reliably infloops unfixed Emacs: > probably not. If the requirement is simply to make some variable > circular and call code which might refer to it, on the off chance that > that code would infloop once in a while, maybe. > > And what if we can't find such a test? I'm pretty sure > find_font_encoding isn't unused, and it will infloop if > Vfont_encoding_alist is circular and we don't want to return one of its > elements, but how do I trigger it? Even if I managed to trigger it on > my system (no luck so far), would that do anything on Windows, with its > totally different font handling code? Wouldn't it depend on which fonts > are installed? I thought concocting tests for this would be easy. If it isn't, we don't have to have such tests. (And Vfont_encoding_alist works on Windows like it works elsewhere. Everything in font.c is platform-independent, with a small number of exceptions explicitly marked by #ifdef's.) Thanks. From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 22:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: acorallo@gnu.org, mattiase@acm.org, eggert@cs.ucla.edu, 75520@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17368928436780 (code B ref 75520); Tue, 14 Jan 2025 22:15:02 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 22:14:03 +0000 Received: from localhost ([127.0.0.1]:56059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXpAh-0001lH-0Z for submit@debbugs.gnu.org; Tue, 14 Jan 2025 17:14:03 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:11625) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXpAd-0001kc-MB for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 17:14:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736892832; x=1737152032; bh=fKK5NQLdFC3vaNzhUp90U6MnIb/iLOCzN9CaxvR/jl0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=P2tJxL3Pu8N2W5ZBUOtQCcI4Ai8JvjI3JcWazu6aeccnSdeY15/5a+VOrXP+vK2Ns i0n1bzCqMyEB4n4Ybnr0I7AVdX6vvs8M6xo15SaaU9eDkLIo7RvZ7FuWq4GLyTDhT5 IAQ/xf90nrbBPujBWkYnLh5mFNM4XLHdSJzIQSPhlsE/cS5PDrr/Z83RNiTJixAZzW Ci7vfIasNwdOr9+IZUH5LNMjRu6xCAE9Annj6RSYAFjP0vnGlA0LxU3C0mN3Q6zf9b 5Ux5Yy3IabAwC+5riuojS5ShlZTCjYuUTf2XLgldMjIb7eDkbJJLmhvaO8uZ+MzeI1 54Bb35g6hVxfg== Date: Tue, 14 Jan 2025 22:13:48 +0000 From: Pip Cet Message-ID: <8734hloxgv.fsf@protonmail.com> In-Reply-To: <8634hlt7yg.fsf@gnu.org> References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> <8634hlt7yg.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: caf5392f0a05e7d20d4f7710856c6c96e07212a6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Tue, 14 Jan 2025 18:45:51 +0000 >> From: Pip Cet >> Cc: Paul Eggert , mattiase@acm.org, monnier@iro.umon= treal.ca, acorallo@gnu.org, 75520@debbugs.gnu.org >> >> > Seems like we have a consensus here that this should be fixed. >> >> I agree, but it's a significant task: My git grep caught ~8 bugs, but >> covered only 22% of cases (at best), so I'd naively expect at least 20 >> bugs, and fixing them is usually simple but occasionally tedious >> (because one might forget to include an additional check, for example, >> as I did when I accidentally removed a STRINGP (XCAR (tem)) on >> scratch/igc). > > We can fix only the most painful ones. We don't need to make sure > none remain, if it isn't easy. It's not. Maybe coccinelle can help, though (Stefan Kangas just used it, so it seems to still exist, and coccigrep at least was updated recently). However, I don't believe we should go to the trouble of identifying bugs and then decide not to fix them. >> > But can we please have at least one test for every place where we fix >> > this kind of bug? >> >> Assuming you mean a test case that reliably infloops unfixed Emacs: >> probably not. If the requirement is simply to make some variable >> circular and call code which might refer to it, on the off chance that >> that code would infloop once in a while, maybe. >> >> And what if we can't find such a test? I'm pretty sure >> find_font_encoding isn't unused, and it will infloop if >> Vfont_encoding_alist is circular and we don't want to return one of its >> elements, but how do I trigger it? Even if I managed to trigger it on >> my system (no luck so far), would that do anything on Windows, with its >> totally different font handling code? Wouldn't it depend on which fonts >> are installed? > > I thought concocting tests for this would be easy. If it isn't, we > don't have to have such tests. Excellent. I'll do the easy tests and report back with a patch, listing those places I couldn't find a test for. > (And Vfont_encoding_alist works on Windows like it works elsewhere. xfont.c calls font_registry_charsets in four places; w32font.c doesn't call it at all. > Everything in font.c is platform-independent, with a small number of > exceptions explicitly marked by #ifdef's.) A lot of the code isn't reachable in the same way; for example, unless I'm quite confused, there's no way to reach the code from bug#75521 on Windows, while it might be possible to reach it on GNU/Linux. I don't know much about font registries, though (it's a workaround for the limitation of 65535 characters/"font", IIUC? Is that limitation still relevant, or are we using new font formats now which aren't subject to it?). Pip From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Jan 2025 23:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: acorallo@gnu.org, mattiase@acm.org, Eli Zaretskii , Paul Eggert , 75520@debbugs.gnu.org Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17368987914804 (code B ref 75520); Tue, 14 Jan 2025 23:54:02 +0000 Received: (at 75520) by debbugs.gnu.org; 14 Jan 2025 23:53:11 +0000 Received: from localhost ([127.0.0.1]:56182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXqic-0001FQ-Ev for submit@debbugs.gnu.org; Tue, 14 Jan 2025 18:53:10 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18306) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXqiY-0001Es-Pc for 75520@debbugs.gnu.org; Tue, 14 Jan 2025 18:53:08 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E36A2442744; Tue, 14 Jan 2025 18:52:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1736898778; bh=IU6GKHFdVATCboUaHYwk3b2KlwR0py6Pv6sFaSXJ28s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hVdLnpyafT+1NA16oXhbRUGTUMfue3Btn+Go0lrwx8uFfVBwDb4PGHgOL23IGWXcc YtQ4K3BvDCYjzn13rYsWMiDwxUOvQw6ti/9qWdvrl1d4DeMxmLi8O92b9LKzoiWL5/ YhaT6bDPjyL+GiZ5QJ5CCXSWG2uxbi5Rt2dyaCfSMrPEfMux01i0vPPB5X/4gJkk9U BKYwC5W7slSUInGMGBX4fReBUPRilPXnxYA7ztPZd1DOn2/nDF2eH3Ez+cjsDKq0a2 D4S5gBC7Lc2z4DynhhVqFVcd4rlAlT386BbsAt/OyR1vSjIzE27CbfqEnfHfNrJMVv iS1QxUzfOwapA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9CE5C442735; Tue, 14 Jan 2025 18:52:58 -0500 (EST) Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 699871207E4; Tue, 14 Jan 2025 18:52:58 -0500 (EST) From: Stefan Monnier In-Reply-To: <87tta1p73h.fsf@protonmail.com> (Pip Cet's message of "Tue, 14 Jan 2025 18:45:51 +0000") Message-ID: References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> Date: Tue, 14 Jan 2025 18:52:57 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.104 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > My preference would be to use FOR_EACH_TAIL where we can, and to retain > that macro's quitting behavior: while the comment claims there is no > reason to quit in FOR_EACH_TAIL because Emacs doesn't support "very > long" lists, I believe that statement to be inaccurate for the MPS > branch. I can easily create a 100-million-entry list on the master > branch, too; it takes a few seconds to create (and a few more to > collect). I guess the impact depends on the time to perform one iteration of the loop. If iterating over the 100 million elements also takes just a few seconds, then I don't see a need to try and `maybe_quit`. FWIW, I find accidental circular lists happen much more often than accidental 100-million-entry lists. [ In any case I think this is mostly irrelevant for the discussion at hand or at least can be decided separately/later. ] > That would mean: > > 1. find likely infloops > 2. prove that the infloop actually is reachable > 3. check each loop for extra conditions > 4. ensure that the loop is a good place to quit > 5. use FOR_EACH_TAIL > 6. write a test for each case > I'm volunteering to do 1, 3, 4, 5. I think (2) is a waste of time, to > be honest: if it looks like a bug and there isn't a clear comment > indicating that it's not one, it should be fixed. (6) is very hard, if > we actually want the test to fail (i.e. infloop) reliably for unfixed > Emacs versions. +1 > If (4) isn't possible, we'll have to put an Flength call somewhere > further up the call chain. For (4) the question is not just "quit" but non-local exit in general since `FOR_EACH_TAIL` can also signal an error. We should likely use `FOR_EACH_TAIL_SAFE` when non-local exits aren't known to be acceptable. > As for (2), consider, for example, the Qerror_conditions property of a > symbol. skip_debugger contains an unprotected loop iterating through > this property (this is the inner loop; the outer loop, iterating over > Vdebug_ignored_errors, definitely can cause an infloop); if we ever > reach that code, we'll infloop. I tried setting the Qerror_conditions > property to a circular list, but it didn't infloop. Do I now go and try > to prove conclusively that every code path that reaches skip_debugger is > actually safe? Yeah, I just took a look and it's nasty. I think we'll usually catch it in `find_handler_clause` (because that one uses `Fmemq`) before we reach that code, but there's probably some way to avoid those `Fmemq`. > I think the effort to do so is disproportionate: let's just use > FOR_EACH_TAIL_SAFE there, even if there is a possibility that it might > not be required for correctness. Agreed. This specific code could likely use `Fmemq` even. >> But can we please have at least one test for every place where we fix >> this kind of bug? Sounds like a lot of work since many of those places can require a fair bit of setup before we can trigger them. Stefan From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Jan 2025 06:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Eli Zaretskii Cc: 75520@debbugs.gnu.org, mattiase@acm.org, acorallo@gnu.org, monnier@iro.umontreal.ca, eggert@cs.ucla.edu Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17369222489572 (code B ref 75520); Wed, 15 Jan 2025 06:25:01 +0000 Received: (at 75520) by debbugs.gnu.org; 15 Jan 2025 06:24:08 +0000 Received: from localhost ([127.0.0.1]:56711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXwox-0002UJ-KS for submit@debbugs.gnu.org; Wed, 15 Jan 2025 01:24:07 -0500 Received: from mail-ed1-x52d.google.com ([2a00:1450:4864:20::52d]:48626) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXwou-0002Tm-8y for 75520@debbugs.gnu.org; Wed, 15 Jan 2025 01:24:05 -0500 Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5d9f0a6adb4so4411143a12.1 for <75520@debbugs.gnu.org>; Tue, 14 Jan 2025 22:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736922238; x=1737527038; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=rrT9tDyV1O85i/zh3o9LjPvwMhjn206gyy/4BiYB7+E=; b=WN0w3DoRveit/+ggD+uDyxbbyCti4XuBJb/0tuhbC/oz+xolALjoxqO9A2ITVmsNAN vRo8I88qAfXZQmL5tAt/jkiY5RsLhGucwrRlz4yETjMIy7qCzVYDHyju8Hqhu1jPzViZ PXsb2jUQmS8AOBeCP9aJkF5GRWAyCcDFE1/QxUevANUhX2xy/ERESpdhyV5jEKBeBR6j mUs6CN6PNlC4J6kXSEJuZ980cBvmtwBzU1VZmC2XXkh9WKsyfktiM9FRYLJUUem2Qng1 bey2TIjoWi9xUCPJYvPkoT6ar+GHsh/V/8Vz/v8rHZfY9brjpMwG10tIsuhtZZW5+E+d x7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736922238; x=1737527038; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rrT9tDyV1O85i/zh3o9LjPvwMhjn206gyy/4BiYB7+E=; b=lmFZqBVhwptfv/SceMz6+k2vf0BZL5rR42JVjpyswpmu79KaFR+XFqAIlBE2NTil/M wTTdRglkIXDiHBph6rx6aqErZBZJQltvi1b6K/EfBqijRFUckjaB3+eowblyQ6i882Wl YnbEqkQYAyOa34GhxcMmu4pZ0W5xz8+jrXB54eTcupRrhNo5OoKLSanudPiF8J3qSnVM mMhc86pbnFOWrOFyCVi8xrRyWozQMqcvgZ2+YyAQDkBjku7loSfAcYuQW/Dubq5FJU9I 7gtQZd3AGkBiPQF3SHGeU4HHv7jVsBN2+3lPMTgE4Dt48gm9bn3QQZqM1F/dAHxibasz A34g== X-Forwarded-Encrypted: i=1; AJvYcCVvFWmfEEQ45h+CK5G+pwRZJzTUAY0PwYOkCS9TMCpPMgtShFIH0XRem9K44NFfDYZeqdUGkA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxnV8CL4yCAB9Nl6WdscXXh9VD39hdJMRnFTNTmHj1DIsdFXVk5 9S2syIWmZboOplVqdAPgv7YAXeiridA7mgRhqoC8vHPjozxDK+DTSiIsnDmwth5ywGc5PEydnDo G7fdfuv1XO9+5pJPpKYV87RtC+5MCBQ== X-Gm-Gg: ASbGncvbpRAnFkFxDHjAQNYlDq2v5iEtTUDSPE0iWXhMQ+387fc/N+o5iWpH6wkQVhv ne8kfqSN2egywW89F9SWuriH5n2R1vQUhqm4aL+UT X-Google-Smtp-Source: AGHT+IEMxUTP6K+10NN//opS2Nv1BZ9x1Ck1ltsii642b/WmKCO+HanN71+axaBfX13/oZhsGUSr+SduBaFNjUDjshM= X-Received: by 2002:a05:6402:35c8:b0:5da:d16:7388 with SMTP id 4fb4d7f45d1cf-5da0d167692mr1265897a12.17.1736922227009; Tue, 14 Jan 2025 22:23:47 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Jan 2025 01:23:46 -0500 From: Stefan Kangas In-Reply-To: <8734hloxgv.fsf@protonmail.com> References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> <8634hlt7yg.fsf@gnu.org> <8734hloxgv.fsf@protonmail.com> MIME-Version: 1.0 Date: Wed, 15 Jan 2025 01:23:46 -0500 X-Gm-Features: AbW1kvZHzzdbxKCEe3Ly1JPdTbuazXcQlbvyqBb_3RGQ6CJocszbk2oXujKs_30 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > "Eli Zaretskii" writes: > >> We can fix only the most painful ones. We don't need to make sure >> none remain, if it isn't easy. > > It's not. Maybe coccinelle can help, though (Stefan Kangas just used > it, so it seems to still exist, and coccigrep at least was updated > recently). AFAIK, it's actively developed and used. Version 1.3.0 was released last November. https://coccinelle.gitlabpages.inria.fr/website/distrib/changes.html From unknown Sun Jun 15 13:02:09 2025 X-Loop: help-debbugs@gnu.org Subject: bug#75520: Circular code or data can hang Emacs unquittably Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Jan 2025 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75520 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: eggert@cs.ucla.edu, 75520@debbugs.gnu.org, mattiase@acm.org, monnier@iro.umontreal.ca, Eli Zaretskii , acorallo@gnu.org Received: via spool by 75520-submit@debbugs.gnu.org id=B75520.17369497607445 (code B ref 75520); Wed, 15 Jan 2025 14:03:02 +0000 Received: (at 75520) by debbugs.gnu.org; 15 Jan 2025 14:02:40 +0000 Received: from localhost ([127.0.0.1]:57298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY3yh-0001vy-RY for submit@debbugs.gnu.org; Wed, 15 Jan 2025 09:02:40 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:32031) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY3yf-0001vb-02 for 75520@debbugs.gnu.org; Wed, 15 Jan 2025 09:02:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736949750; x=1737208950; bh=P1ZSEXlEa0vk66G0pWMtUE3KS9zVxMEP4VzTo8OIp3o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=NZ5f3dSOSpPk7Xrn6AUBk7d31LPTLNsE0/q5uxh9GpNEBAh+zDl2iLF9ZRPNbufAT 8UYAW6LadmOOCRFvIgUN44R1jqjmSqrNm+4C0j8HE7Dc45J/Jwiced4j20kYd8j9qi abcXuEcLoTH2ogJRXU1YmKR6GpQIdam3Gl1qGnh7XHa2GgwqMQF9BlqCLG4Ze86pR7 rzfbTlmYltf8GYUbficWD6w6LO+3X8KMafn8sdCMFnFNNO4AhSPoEzhAKD2mwwyPAR Xc56Aiq1ebAhc/Z5oDQdWVjSUnYhp9thj2GTg3fwpVD4Q1paYcQAXNvE4aD92HSjzD B3+jK6s6inNEw== Date: Wed, 15 Jan 2025 14:02:25 +0000 From: Pip Cet Message-ID: <87bjw8npjy.fsf@protonmail.com> In-Reply-To: References: <87tta4ufi8.fsf@protonmail.com> <86r057x48i.fsf@gnu.org> <787f5d13-5a2d-4fcb-ab14-b56008e640f1@cs.ucla.edu> <87zfjvu2mb.fsf@protonmail.com> <26dc7a0c-9f3b-43c6-9e80-4b951f90eb71@cs.ucla.edu> <86bjw9tkyf.fsf@gnu.org> <87tta1p73h.fsf@protonmail.com> <8634hlt7yg.fsf@gnu.org> <8734hloxgv.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7746c1dd64dc089be5031be6509ddd8e1019f424 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Stefan Kangas" writes: > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text > editors" writes: > >> "Eli Zaretskii" writes: >> >>> We can fix only the most painful ones. We don't need to make sure >>> none remain, if it isn't easy. >> >> It's not. Maybe coccinelle can help, though (Stefan Kangas just used >> it, so it seems to still exist, and coccigrep at least was updated >> recently). > > AFAIK, it's actively developed and used. Version 1.3.0 was released > last November. Thanks! Here's what I'm going to do (this is long, but I'd appreciate feedback on how to improve the coccinelle scripts in particular!): 1. DONE: coccinelle script to detect likely loops 2. TODO: improve coccinelle script to un-detect likely loops that call an infloop-breaking function 3. DONE: additional compile-time reporting of globals used in likely loops 4. TODO: go through all of them :-) Coccinelle doesn't seem to handle do { ... } while (...); loops, but we don't really need those: the only two hits would be timer_check_2 and validate_plist. (timer_check is probably a problem: it calls copy-sequence on Vtimer_list and Vtimer_idle_list, which may throw while input is blocked and inhibit-quit is t. It would be really nice to mark critical sections which should not ever throw a signal so we can eassert that we're not in one, but that's only a runtime check...) Here are the cocci files I'm using: // Find loops for bug#75520: Circular code or data can hang Emacs unquittab= ly // This file cannot be applied to intervals.c, because that contains a // double loop which matches the pattern in two different ways. @@ identifier A; expression R; expression R2; @@ + maybe_circular(A); while ( ( CONSP (A) | R && CONSP (A) | CONSP (A) && R | R && CONSP (A) && R2 ) ) { <... A =3D XCDR (A); ...> } // Find loops for bug#75520: Circular code or data can hang Emacs unquittab= ly @@ identifier A; expression E; expression E2; expression R; expression R2; @@ +E; +maybe_circular (A); -for (E; +for (; ( CONSP (A) | CONSP (A) && R | R && CONSP (A) | R && CONSP (A) && R2 ); E2) { <... A =3D XCDR(A); ...> } (Note that coccinelle is smart enough to find "A =3D XCDR(A);" even if that is the third sub-expression "argument" of the for statement. This makes things a lot easier.) These add calls to a new macro, maybe_circular, to happen right before the first iteration of the loop. It also breaks coding.c, because it matches a for loop definition in a macro, but fails to add the necessary final backslash to the new line it produces. So we could leave it at that, and go over the diff, removing calls to maybe_circular that are safe. If we had a list of function calls which we know prevent an infloop (such as maybe_quit, Flength(A), etc.), we could create another .cocci file to remove maybe_circular automatically if the loop is likely to be safe, but that would probably involve a small number of false negatives if the call to the infloop-preventing function is conditional. To get a quick list of global variables which are known to appear in such loops, this works (but, probably, only on ELF systems; definitely requires optimization, probably doesn't work with clang): #define is_tainted_global(v, v2, s) ({=09=09=09=09=09\ if (__builtin_constant_p ((v) =3D=3D (v2)))=09=09=09=09\ {=09=09=09=09=09\ asm volatile (".pushsection .tainted_globals,\"aw\"\n\t"=09\ =09 ".asciz \"" s "\"\n\t"=09=09=09\ =09=09 ".popsection" : : "i" (&v2));=09=09\ }=09=09=09=09=09\ }) #include "tainted.h" #define maybe_circular(v) ({=09=09=09\ is_tainted (v);=09=09=09=09\ 1;=09=09=09=09=09=09\ }) where tainted.h is generated by this bash script: (echo "#define is_tainted(v) ({ \\"; (grep ' Lisp_Object f_V' | sed -e 's/ Lisp_Object f_//g' | sed -e 's/;$//= ' | while read; do echo "is_tainted_global(v, $REPLY, \"$REPLY\"); \\"; don= e) < globals.h; echo "})") > tainted.h This puts the names of all global variables which are known to appear in potentially circular loops into an ELF section: Contents of section .tainted_globals: 67ed60 566f7665 726c6179 5f617272 6f775f76 Voverlay_arrow_v 67ed70 61726961 626c655f 6c697374 00566f76 ariable_list.Vov 67ed80 65726c61 795f6172 726f775f 76617269 erlay_arrow_vari 67ed90 61626c65 5f6c6973 7400566f 7665726c able_list.Voverl 67eda0 61795f61 72726f77 5f766172 6961626c ay_arrow_variabl 67edb0 655f6c69 73740056 6f766572 6c61795f e_list.Voverlay_ 67edc0 6172726f 775f7661 72696162 6c655f6c arrow_variable_l 67edd0 69737400 5677696e 646f775f 70657273 ist.Vwindow_pers 67ede0 69737465 6e745f70 6172616d 65746572 istent_parameter 67edf0 73005677 696e646f 775f7065 72736973 s.Vwindow_persis 67ee00 74656e74 5f706172 616d6574 65727300 tent_parameters. 67ee10 5677696e 646f775f 70657273 69737465 Vwindow_persiste 67ee20 6e745f70 6172616d 65746572 73005663 nt_parameters.Vc 67ee30 6f6d706c 6574696f 6e5f7265 67657870 ompletion_regexp 67ee40 5f6c6973 74005663 6f6d706c 6574696f _list.Vcompletio 67ee50 6e5f6967 6e6f7265 645f6578 74656e73 n_ignored_extens 67ee60 696f6e73 0056636f 6d706c65 74696f6e ions.Vcompletion 67ee70 5f69676e 6f726564 5f657874 656e7369 _ignored_extensi 67ee80 6f6e7300 56646562 75675f69 676e6f72 ons.Vdebug_ignor 67ee90 65645f65 72726f72 73005666 6f6e745f ed_errors.Vfont_ 67eea0 656e636f 64696e67 5f616c69 73740056 encoding_alist.V 67eeb0 66616365 5f666f6e 745f7265 7363616c face_font_rescal 67eec0 655f616c 69737400 56736372 6970745f e_alist.Vscript_ 67eed0 72657072 6573656e 74617469 76655f63 representative_c 67eee0 68617273 00567363 616c6162 6c655f66 hars.Vscalable_f 67eef0 6f6e7473 5f616c6c 6f776564 00 onts_allowed. =20 This finds both cases that are actually safe (Vwindow_persistent_parameters has its own cycle detection: no teleporting there) and cases that seem unsafe (Vcompletion_ignored_extensions). Somewhat independently of this, we might want to put static Lisp_Objects into a separate section: this allows us to make staticpro of such objects a nop and simply protect the entire section. Similarly, we can make global Lisp_Object "variables" (actually elements of struct emacs_globals) contiguous in memory, and protect them all at once, omitting the staticpro calls for that case as well. This would require changes to make-docfile.c which should also allow us to conditionalize DEFVAR_LISP/DEFSYM in a way that detects unreachable DEFVAR_LISP/DEFSYM "calls" and doesn't create variables for all of them. (For example, right now, builds without nativecomp still defsym some 65 symbols from comp.c, wasting space in lispsym and for the symbol name). (Another reason we may want to touch make-docfile.c is that we sometimes use uninitialized global Lisp variables; if they were contiguous in memory, we could simply poison them and catch such errors. I know this approach works because if I poison the entire globals area, it allows me to catch one such bug before crashing because non-Lisp-Object globals are also poisoned: Voverriding_plist_environment is used by init_syntax_once() but only initialized by syms_of_fns()) These changes should help performance, particularly with MPS, and may allow protecting the static/global areas with memory barriers, which may or may not help performance further (it may help debugging to put each Lisp_Object on a separate page). I also think this should allow us to add runtime checks ensuring that certain static Lisp_Objects do not ever refer to circular objects. So that's my approach: coccinelle for static analysis, compile-time analysis producing an ELF section of likely tainted globals, and potentially changes to ensure certain statics are non-circular at runtime. Of course, the first thing to do for any such changes is to remove DEFVAR_LISP_NOPRO; see bug#75521 for a very lengthy discussion of this question; IIUC, the conclusion is that the master branch will retain DEFVAR_LISP_NOPRO for now, which complicates things significantly. Pip