From unknown Mon Jun 23 02:22:10 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#65796 <65796@debbugs.gnu.org> To: bug#65796 <65796@debbugs.gnu.org> Subject: Status: dynamic module non_local_exit_get overwrites exit signals Reply-To: bug#65796 <65796@debbugs.gnu.org> Date: Mon, 23 Jun 2025 09:22:10 +0000 retitle 65796 dynamic module non_local_exit_get overwrites exit signals reassign 65796 emacs submitter 65796 Xinyang Chen severity 65796 normal tag 65796 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 07 00:58:42 2023 Received: (at submit) by debbugs.gnu.org; 7 Sep 2023 04:58:42 +0000 Received: from localhost ([127.0.0.1]:38293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qe76G-0002dV-Mf for submit@debbugs.gnu.org; Thu, 07 Sep 2023 00:58:42 -0400 Received: from lists.gnu.org ([2001:470:142::17]:38400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qe1O0-0001w6-Hb for submit@debbugs.gnu.org; Wed, 06 Sep 2023 18:52:51 -0400 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 1qe1Nt-0002y7-Qz for bug-gnu-emacs@gnu.org; Wed, 06 Sep 2023 18:52:29 -0400 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qe1Nr-0004dq-Jn for bug-gnu-emacs@gnu.org; Wed, 06 Sep 2023 18:52:29 -0400 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5008faf4456so476971e87.3 for ; Wed, 06 Sep 2023 15:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694040745; x=1694645545; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=UEGDdO1L0h3GqkNVTA7xe3xYmYuPQ6k7cPE2FglE94g=; b=RplZt4rnN+ohxxmfyNWqX75hEUk8Grlu3xwY56fKKDc4LX1Z06mT4PtciMq8BTPN1t ezi11DqnywJ2H7ReA7FXx3Psq/E2nfkPJc8RbUXzv4n45eGF653tA0FOYqked9cuI3PV XUR57pfg8VnJZArf65O52bWqz3vu9JOY+GTPucuu7TEYDmpeUa/Oa+F/2w4VpDsC89p6 c4wQ7mNcnTk4eSvTkAV98+VgfTTlMFJpMksDBL4t57ykteQ4ubno2eNysJgN7uLry3FW TKhBgglM/D0wEDOqw8Y3R08k+sGMzIUuRXx54Q1Cc4vq9wjqvnrmnRYpJY0yTt09y1G9 2DyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694040745; x=1694645545; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UEGDdO1L0h3GqkNVTA7xe3xYmYuPQ6k7cPE2FglE94g=; b=dqp6+hRAixZU55YW4jJibUbVu6KP8bUoJUISR0Wr8/NX4GUcw41dV3+r/tRWR3KRHa p01tMb/jnFMjyoY8zNJQODouP5ZXfSzq7bC+8Fj6J1hTazoHF8ozrmYEdQlKulZX+1ZX NgQIS+gkayRtw/khUi/4f3WfBer/ERPpArKD0HM7klHrlqasIhTIpk8AP0XZSuVzW211 8dZctM9sPLS6dZAa3c95b9TdDQxPouSCdis1dLnyHV4SjUOM8IIVJ4Dn5oqCl3W6gOMc x0PhsYEvUecivy90LcriLbHO22ceHXNR3omnkbqXYgVwW/SRtKIpYSrAtIPcL3369ORT 09zA== X-Gm-Message-State: AOJu0Yw2y+3DTdIyF67tKTPL0rT/CXc1/VbmhXTNtS/EOW2elfKvuAkj FasoUguBhGmMXd77qeILoSSplP8gtURXOKsBKXjBM7+o8QwldQ== X-Google-Smtp-Source: AGHT+IHpVKT6FbIDG/m6WrLPr1fIKiHtxmlUV25GrILNDhJj1dpTcaP35he2zM78YxW4I7CcY7fvxBiNHbDzow0/okg= X-Received: by 2002:ac2:4830:0:b0:500:bf33:3add with SMTP id 16-20020ac24830000000b00500bf333addmr3195110lft.47.1694040744858; Wed, 06 Sep 2023 15:52:24 -0700 (PDT) MIME-Version: 1.0 From: Xinyang Chen Date: Wed, 6 Sep 2023 18:52:14 -0400 Message-ID: Subject: dynamic module non_local_exit_get overwrites exit signals To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000d51bc30604b89823" Received-SPF: pass client-ip=2a00:1450:4864:20::135; envelope-from=chenxinyang99@gmail.com; helo=mail-lf1-x135.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Currently `module_non_local_exit_get` returns pointers to fields in emacs_env_private: ``` if (p->pending_non_local_exit != emacs_funcall_exit_return) { *symbol = &p->non_local_exit_symbol; *data = &p [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (chenxinyang99[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (chenxinyang99[at]gmail.com) 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 HTML_MESSAGE BODY: HTML included in message X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 07 Sep 2023 00:58:39 -0400 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.2 (/) --000000000000d51bc30604b89823 Content-Type: text/plain; charset="UTF-8" Currently `module_non_local_exit_get` returns pointers to fields in emacs_env_private: ``` if (p->pending_non_local_exit != emacs_funcall_exit_return) { *symbol = &p->non_local_exit_symbol; *data = &p->non_local_exit_data; } ``` this means that if one tries to: ``` funcall(...); non_local_exit_get(&s1, &d1); funcall(...); non_local_exit_get(&s2, &d2); non_local_exit_signal(s1, d1); ``` you would signal the second error, instead of the first error (I expected this to happen). It seems to me that `module_non_local_exit_get` should `allocate_emacs_value` instead. -Alan --000000000000d51bc30604b89823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently=C2=A0`module_non_local_exit_get` returns=C2=A0po= inters to fields in=C2=A0emacs_env_private:
```
=C2=A0 if (p-= >pending_non_local_exit !=3D emacs_funcall_exit_return)
=C2=A0 =C2=A0= {
=C2=A0 =C2=A0 =C2=A0 *symbol =3D &p->non_local_exit_symbol;=C2=A0 =C2=A0 =C2=A0 *data =3D &p->non_local_exit_data;
=C2=A0 = =C2=A0 }
```
this means that if one tries to:
`= ``
funcall(...);
non_local_exit_get(&s1, &d1);
funcall(...);
non_local_exit_get(&s2, &d= 2);
non_local_exit_signal(s1, d1);
```
you would=C2=A0signal the second error, instead of the first error (I= expected this to happen).
It seems to me that `module_non_= local_exit_get` should `allocate_emacs_value` instead.

=
-Alan
--000000000000d51bc30604b89823-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 07 03:07:55 2023 Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 07:07:55 +0000 Received: from localhost ([127.0.0.1]:38410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qe97K-00063m-TU for submit@debbugs.gnu.org; Thu, 07 Sep 2023 03:07:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qe97J-00063Z-IY for 65796@debbugs.gnu.org; Thu, 07 Sep 2023 03:07:54 -0400 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 1qe97C-0007EL-5X; Thu, 07 Sep 2023 03:07:46 -0400 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=BK3rW+eT2Jcc9r6id1iYqQZrsy1nKvCwc5oabv7D6Mk=; b=i5IR9+5q4esT uNggmLyKlRBHB9n2SoCIwPEU4ZH97sRaJekh2m2LC09tC4x7AFNsBaAfRpjAf+YR0mtoO6m53ABYM KCK1VkpTbGsZsZtR2WymQX7vXZ8CYc24mB8+oJ7hqOyMQAkGRvbiPF9E5gBpyS+5B8I85bcKJo/v+ otQl9GTmh9RX3rml/pDJE+88LulAgS8uhu2eDvhLZZgF5ySRAq0RrTyKoiRTDUnaTx7QcIGDTgHTG 1vEucXlRGIJpl6BDKcCtlBUJpTUP7WMccpqTURtClwx56sYl61q3octcB4r6kVX4f07AgO16YBVTl 140SKbiFvq6mLvdPvBHztw==; Date: Thu, 07 Sep 2023 10:07:33 +0300 Message-Id: <8334zq1mx6.fsf@gnu.org> From: Eli Zaretskii To: Xinyang Chen , Philipp Stephani , Daniel Colascione In-Reply-To: (message from Xinyang Chen on Wed, 6 Sep 2023 18:52:14 -0400) Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65796 Cc: 65796@debbugs.gnu.org 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 (---) > From: Xinyang Chen > Date: Wed, 6 Sep 2023 18:52:14 -0400 > > Currently `module_non_local_exit_get` returns pointers to fields > in emacs_env_private: > ``` > if (p->pending_non_local_exit != emacs_funcall_exit_return) > { > *symbol = &p->non_local_exit_symbol; > *data = &p->non_local_exit_data; > } > ``` > this means that if one tries to: > ``` > funcall(...); > non_local_exit_get(&s1, &d1); > funcall(...); > non_local_exit_get(&s2, &d2); > non_local_exit_signal(s1, d1); > ``` > you would signal the second error, instead of the first error (I expected > this to happen). > It seems to me that `module_non_local_exit_get` should > `allocate_emacs_value` instead. Philipp, Daniel: any comments? Btw, the non_local_exit_get function is currently not documented in the ELisp manual; should it be? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 07 06:24:30 2023 Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 10:24:30 +0000 Received: from localhost ([127.0.0.1]:38698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeCBa-0005Np-1u for submit@debbugs.gnu.org; Thu, 07 Sep 2023 06:24:30 -0400 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:36089) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeCBY-0005Nd-Lw for 65796@debbugs.gnu.org; Thu, 07 Sep 2023 06:24:29 -0400 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-51e24210395so11114a12.0 for <65796@debbugs.gnu.org>; Thu, 07 Sep 2023 03:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694082261; x=1694687061; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QMqBwGul96xihfaV6H0gOMf/kK0hd+bVLZwS3P7t9LY=; b=vD77yKWwMbY+OAE82PhMc1a+A/FqLQ3pB71hWn8RjHMldSq5kz5vJTRy2WFvrUIlye pm3j+EUnzVho660iSh5gSXqDSIeDTjXa6vQq+tB7gB/xmqtzcU0ZR1YEqpRvp5b2p8v+ 80a0g0yc8ZPL2cvRL4aw5fAshXm/GIzFi2jIPy21s7qjL4mQACAv4CKfVTzpY2gpWJ9j 2gai2pS3Di6kmRgq9QBL4sbI3+EJWxCyCQff0K+k9OZEYdyrzlL1sW8tc7aTewqX0eHl 71gV5ubRD1PXqZryBd9fILA2kCDGtvTa/alhKS+iNSFisrvj+CC+dtBy7FQct7LBEq8W mIiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694082261; x=1694687061; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QMqBwGul96xihfaV6H0gOMf/kK0hd+bVLZwS3P7t9LY=; b=FQUMZrcffRTemRACQ0TIm8rC6J+fLmWSjM9G8Q+E7ahqHz3uxwv5D+TMg5WP4l49aW LmPm0sAPjlCOVP0IwjP5JLG14a7unmMdCT16BTUr2brZpe7Kma+v+nacQyZgUxAxke8g LFBKOtwhj5REANU5KcuKs56jmhh1PkjGt9s2dfHdjbZVHC2ug4AH5TZeqrpF7ZEw7GxK BRatCU6P/jvsm3LvrPP5QvIYv8HJ/Ah5PGBdBodWTessL4jC0IrcPc49ror3jfMfsol1 ZFzbRkpn3jPW9hwUFJlvIPyIDripMkU+itZG4SCccn0kzVPKnPL3vH0O3KzO3R2I74PD 3T4A== X-Gm-Message-State: AOJu0Yy5dDwU6gcPgmb14Qo/5p49EBHr+xipxuRrmHGNFkDXyZxpkM7q INp27BDAuacawOD5ZuseHXycWZ4hoawZTPxyrc7tLg== X-Google-Smtp-Source: AGHT+IFRbVWKm09CmY2Tqjzhk751oh+VYO5On7AaytSHvVaEXuE/ETRAOSQR2F4Lhn8TM/pjUKJ8gV9tu89/gkPkdwU= X-Received: by 2002:a50:d089:0:b0:522:cc9c:f5a4 with SMTP id v9-20020a50d089000000b00522cc9cf5a4mr99251edd.4.1694082260577; Thu, 07 Sep 2023 03:24:20 -0700 (PDT) MIME-Version: 1.0 References: <8334zq1mx6.fsf@gnu.org> In-Reply-To: <8334zq1mx6.fsf@gnu.org> From: Philipp Stephani Date: Thu, 7 Sep 2023 12:24:03 +0200 Message-ID: Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -8.0 (--------) X-Debbugs-Envelope-To: 65796 Cc: Xinyang Chen , p.stephani2@gmail.com, Daniel Colascione , 65796@debbugs.gnu.org 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: -9.0 (---------) On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii wrote: > > > From: Xinyang Chen > > Date: Wed, 6 Sep 2023 18:52:14 -0400 > > > > Currently `module_non_local_exit_get` returns pointers to fields > > in emacs_env_private: > > ``` > > if (p->pending_non_local_exit !=3D emacs_funcall_exit_return) > > { > > *symbol =3D &p->non_local_exit_symbol; > > *data =3D &p->non_local_exit_data; > > } > > ``` > > this means that if one tries to: > > ``` > > funcall(...); > > non_local_exit_get(&s1, &d1); > > funcall(...); > > non_local_exit_get(&s2, &d2); > > non_local_exit_signal(s1, d1); > > ``` > > you would signal the second error, instead of the first error (I expect= ed > > this to happen). > > It seems to me that `module_non_local_exit_get` should > > `allocate_emacs_value` instead. > > Philipp, Daniel: any comments? Nice find! We can't use allocate_emacs_value here because non_local_exit_get has to work in OOM situations and can never fail. What we could do here is e.g.: - Document the current behavior, stating that the emacs_value objects returned from non_local_exit_get are ephemeral. I'm not a huge fan of this because it makes non_local_exit_get behave different from all other functions. - Provide an alternative non_local_exit_copy that copies the 2 Lisp_Objects into an opaque buffer supplied by the user (plus a way to determine the buffer size). That way we shift the responsibility of dealing with allocation failures to the user. - Attempt to allocate a new emacs_value, fall back to the current behavior if that fails. I don't really like that option either because it doesn't solve the initial problem in all cases (so users still need to deal with it), but makes both the interface and the implementation more complex. - Crash if we can't allocate memory. That has been rejected in other cases. > > Btw, the non_local_exit_get function is currently not documented in > the ELisp manual; should it be? At least in Emacs 29 I see it documented ("Module Nonlocal" node). -- Google Germany GmbH Erika-Mann-Stra=C3=9Fe 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie = mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. This e-mail is confidential. If you received this communication by mistake, please don=E2=80=99t forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 07 06:55:36 2023 Received: (at 65796) by debbugs.gnu.org; 7 Sep 2023 10:55:36 +0000 Received: from localhost ([127.0.0.1]:38733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeCff-0006LZ-Iy for submit@debbugs.gnu.org; Thu, 07 Sep 2023 06:55:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52582) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qeCfa-0006LJ-OP for 65796@debbugs.gnu.org; Thu, 07 Sep 2023 06:55:34 -0400 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 1qeCfT-00061O-3z; Thu, 07 Sep 2023 06:55:23 -0400 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=w05iH/8akOLHstJpHJstWmKEG9B7AXKQAJWYAubEtP8=; b=F/WBy237w0RX s5wOyjB8R0apQIxJgRZq89ZUZl988Zd8qhwcnguei/RFumqkayCH2Me5UbNs+yQCmKem180soZBbI zuDlXdfE0OD8rsIl0JByi/1HQQk4W+mHaMdDdH1v4y6AnsLHkRMH4QclBIj6PdVAxx/ZPJ31y0ICg Wu+dh4MSzhEgXdT7NlEQl/709j8yLZvtMFt6eFDMRr+1AM8E0x5+Xh/VNej39O1d9hxpXtnn+fmP9 LM3nrEMfwT9JD2VGpVlldfHEg5GIE4dXa1MmgPP5wUfDODqyycetgzjPxHSlj+s8lXWi8oBwv06oL lcl9mXrGpLcI+AQQ65nWpw==; Date: Thu, 07 Sep 2023 13:55:09 +0300 Message-Id: <83h6o6z20i.fsf@gnu.org> From: Eli Zaretskii To: Philipp Stephani In-Reply-To: (message from Philipp Stephani on Thu, 7 Sep 2023 12:24:03 +0200) Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals References: <8334zq1mx6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65796 Cc: chenxinyang99@gmail.com, p.stephani2@gmail.com, dancol@dancol.org, 65796@debbugs.gnu.org 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 (---) > From: Philipp Stephani > Date: Thu, 7 Sep 2023 12:24:03 +0200 > Cc: Xinyang Chen , Daniel Colascione , 65796@debbugs.gnu.org, > p.stephani2@gmail.com > > Nice find! > We can't use allocate_emacs_value here because non_local_exit_get has > to work in OOM situations and can never fail. What we could do here is > e.g.: > - Document the current behavior, stating that the emacs_value objects > returned from non_local_exit_get are ephemeral. I'm not a huge fan of > this because it makes non_local_exit_get behave different from all > other functions. > - Provide an alternative non_local_exit_copy that copies the 2 > Lisp_Objects into an opaque buffer supplied by the user (plus a way to > determine the buffer size). That way we shift the responsibility of > dealing with allocation failures to the user. > - Attempt to allocate a new emacs_value, fall back to the current > behavior if that fails. I don't really like that option either because > it doesn't solve the initial problem in all cases (so users still need > to deal with it), but makes both the interface and the implementation > more complex. > - Crash if we can't allocate memory. That has been rejected in other cases. I guess just one alternative is acceptable? > > Btw, the non_local_exit_get function is currently not documented in > > the ELisp manual; should it be? > > At least in Emacs 29 I see it documented ("Module Nonlocal" node). I need new glasses. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 29 12:53:02 2025 Received: (at 65796) by debbugs.gnu.org; 29 Jan 2025 17:53:03 +0000 Received: from localhost ([127.0.0.1]:42905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tdCFK-00027M-5S for submit@debbugs.gnu.org; Wed, 29 Jan 2025 12:53:02 -0500 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:49259) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tdCFH-00026m-Qe for 65796@debbugs.gnu.org; Wed, 29 Jan 2025 12:53:01 -0500 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-543e47e93a3so1422468e87.2 for <65796@debbugs.gnu.org>; Wed, 29 Jan 2025 09:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738173173; x=1738777973; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wio1PX/4UBRIhg4xhhhaVZooTECCyYQVXFTW8vAkCtM=; b=TftjXQ0LYWH0pdvVsdi55orFTxia4Vdmow7Vfskwthc7L1Veme6WrRN70jOg1ZKGn0 jd8PR/IOSB2vCHzunWXol+HUBPnpRMkcy0jE70En9Hdih+hA4ZNQ4K5F2XxwC0upSTCK pzybgqdflKgeOGiO2tv5mnDKUhpyjR97EzsJaiNSB4cHu5CCsQ5mwrsW+IhOaX7kO+dc aM3PbslZKqXL1mLqvgZXjOc7Opj5a6yRUJedoPvl2PkYz2LCXGpAkLiNO3ZW3B+V2VZz 8Ku/1+fnH2UfsJd9toMPJEwIEPj72ekh5CohaISLU415t2AWMMIwOBokTVi6U6w9psz3 JJjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738173173; x=1738777973; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wio1PX/4UBRIhg4xhhhaVZooTECCyYQVXFTW8vAkCtM=; b=IoxfGI7lYWWH7K41pr1xheWMyPtT/UPUC3QtUDgqr2dPbrOnFux2SxexuGoRVPydpI tzWtvH0ZxvqaBBgxV0YO/T5SHYGAQPML1KztkRebnadvDlHTuIc010sjjKwASlqqTr6G wAVQ8qWAh68UITVAGK5xVapcWCHCsv+azILdjasyTceFpNUtPlgvDijIDTouM7C2zeve G9MHi1QXD45RJXL+fWa+r/JiUTmMQq3GhU9syrePrOfi41GTMEWzC73PcMrv0+AHzFMN N1eWZVqnD/Pmot024HznldSEOWlBNTEYOR3pTE8JuctOiU17Ey2WlWX7yB/C5zbtt9Is ZgIw== X-Forwarded-Encrypted: i=1; AJvYcCVsSZof5NINHQc+KQITDoCX6U96465KZ3/SERMONL1BCFOx4jZ8hW14leK8POXpfwbIQ0PyuQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyUVDWCByuqMclj8PRPd/CDjZpSFxGedXzBBEwdpG3d4h8B0N03 8k7Qm8PPgY/7Jg2Spg901LlfHG3c4wLDhwEMeffYxhX0S4D9h/mWj/VOgLSrwqo0yFKm1SrT3JF /HghJdTdOEMX04aNfSr3sgXkbvMU= X-Gm-Gg: ASbGncsHT8fGW//+vvdfChnb0NgBzRyLqaBxI4flVdGTZoIinQivZTsK4eSloWOu67/ 54zlkx4/b634zQNd06QVNshpxqLNCCSpZcZCl8VkkmA8nRHgPwtidybxNpZPDaj6Rw0Rwbjis X-Google-Smtp-Source: AGHT+IE+UYT9U1n82iJCnMse1Tg1eua1LBrStPb6innbPspwrkfwNbq4DzV2EsNlBTlgX+NxmWOa8+CxpZSuPVkwBsw= X-Received: by 2002:a05:6512:3d86:b0:543:bb21:4245 with SMTP id 2adb3069b0e04-543e4c037a3mr1535160e87.28.1738173172925; Wed, 29 Jan 2025 09:52:52 -0800 (PST) MIME-Version: 1.0 References: <8334zq1mx6.fsf@gnu.org> In-Reply-To: From: Xinyang Chen Date: Wed, 29 Jan 2025 11:52:40 -0600 X-Gm-Features: AWEUYZlX_4c8vU5zzsna279xfrgoFg8cJix9_G_pzXG8POZT_eKjkoxB0FO_ENQ Message-ID: Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals To: Philipp Stephani Content-Type: multipart/alternative; boundary="00000000000087d0b2062cdbfae2" X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 65796 Cc: Eli Zaretskii , Daniel Colascione , 65796@debbugs.gnu.org, p.stephani2@gmail.com 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.7 (/) --00000000000087d0b2062cdbfae2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is still a problem. Using a user buffer will require gc-protecting it and thus a major overhaul, so I think it's not a good idea. IMO what we should do is: if we fail to allocate, we discard the original signal and replace it with an OOM signal (pointing to constants so requiring no allocation). Perhaps we should make a new field in emacs_funcall_exit for OOM, or we can just use emacs_funcall_exit_signal= . Alternatively, make a copy_emacs_value function that allows the user to copy the signal out, returning NULL to let the caller know that an allocation failure occurred. On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani w= rote: > On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii wrote: > > > > > From: Xinyang Chen > > > Date: Wed, 6 Sep 2023 18:52:14 -0400 > > > > > > Currently `module_non_local_exit_get` returns pointers to fields > > > in emacs_env_private: > > > ``` > > > if (p->pending_non_local_exit !=3D emacs_funcall_exit_return) > > > { > > > *symbol =3D &p->non_local_exit_symbol; > > > *data =3D &p->non_local_exit_data; > > > } > > > ``` > > > this means that if one tries to: > > > ``` > > > funcall(...); > > > non_local_exit_get(&s1, &d1); > > > funcall(...); > > > non_local_exit_get(&s2, &d2); > > > non_local_exit_signal(s1, d1); > > > ``` > > > you would signal the second error, instead of the first error (I > expected > > > this to happen). > > > It seems to me that `module_non_local_exit_get` should > > > `allocate_emacs_value` instead. > > > > Philipp, Daniel: any comments? > > Nice find! > We can't use allocate_emacs_value here because non_local_exit_get has > to work in OOM situations and can never fail. What we could do here is > e.g.: > - Document the current behavior, stating that the emacs_value objects > returned from non_local_exit_get are ephemeral. I'm not a huge fan of > this because it makes non_local_exit_get behave different from all > other functions. > - Provide an alternative non_local_exit_copy that copies the 2 > Lisp_Objects into an opaque buffer supplied by the user (plus a way to > determine the buffer size). That way we shift the responsibility of > dealing with allocation failures to the user. > - Attempt to allocate a new emacs_value, fall back to the current > behavior if that fails. I don't really like that option either because > it doesn't solve the initial problem in all cases (so users still need > to deal with it), but makes both the interface and the implementation > more complex. > - Crash if we can't allocate memory. That has been rejected in other case= s. > > > > > Btw, the non_local_exit_get function is currently not documented in > > the ELisp manual; should it be? > > At least in Emacs 29 I see it documented ("Module Nonlocal" node). > > > -- > Google Germany GmbH > Erika-Mann-Stra=C3=9Fe 33 > 80636 M=C3=BCnchen > > Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian > Registergericht und -nummer: Hamburg, HRB 86891 > Sitz der Gesellschaft: Hamburg > > Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise > erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes > weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Si= e mich > bitte wissen, dass die E-Mail an die falsche Person gesendet wurde. > > This e-mail is confidential. If you received this communication by > mistake, please don=E2=80=99t forward it to anyone else, please erase all > copies and attachments, and please let me know that it has gone to the > wrong person. > --00000000000087d0b2062cdbfae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is still a problem.

Using a user buffer will require gc-protecting it and = thus a major overhaul, so I think it's=C2=A0not a good idea.
=
IMO what we should do is: if we fail to allocate, we discard= the original signal and replace it with an OOM signal (pointing to constan= ts so requiring no allocation). Perhaps we should make a new field in=C2=A0= emacs_funcall_exit for OOM, or we can just use emacs_funcall_exit_signal.

Alternatively, make a copy_emacs_value function tha= t allows the user to copy the signal out, returning NULL to let the caller = know that an allocation failure occurred.



On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani &= lt;phst@google.com> wrote:
On Thu, 7 Sept 2023 at= 09:07, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Xinyang Chen <chenxinyang99@gmail.com>
> > Date: Wed, 6 Sep 2023 18:52:14 -0400
> >
> > Currently `module_non_local_exit_get` returns pointers to fields<= br> > > in emacs_env_private:
> > ```
> >=C2=A0 =C2=A0if (p->pending_non_local_exit !=3D emacs_funcall_e= xit_return)
> >=C2=A0 =C2=A0 =C2=A0{
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*symbol =3D &p->non_local_exit_s= ymbol;
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*data =3D &p->non_local_exit_dat= a;
> >=C2=A0 =C2=A0 =C2=A0}
> > ```
> > this means that if one tries to:
> > ```
> > funcall(...);
> > non_local_exit_get(&s1, &d1);
> > funcall(...);
> > non_local_exit_get(&s2, &d2);
> > non_local_exit_signal(s1, d1);
> > ```
> > you would signal the second error, instead of the first error (I = expected
> > this to happen).
> > It seems to me that `module_non_local_exit_get` should
> > `allocate_emacs_value` instead.
>
> Philipp, Daniel: any comments?

Nice find!
We can't use allocate_emacs_value here because non_local_exit_get has to work in OOM situations and can never fail. What we could do here is
e.g.:
- Document the current behavior, stating that the emacs_value objects
returned from non_local_exit_get are ephemeral. I'm not a huge fan of this because it makes non_local_exit_get behave different from all
other functions.
- Provide an alternative non_local_exit_copy that copies the 2
Lisp_Objects into an opaque buffer supplied by the user (plus a way to
determine the buffer size). That way we shift the responsibility of
dealing with allocation failures to the user.
- Attempt to allocate a new emacs_value, fall back to the current
behavior if that fails. I don't really like that option either because<= br> it doesn't solve the initial problem in all cases (so users still need<= br> to deal with it), but makes both the interface and the implementation
more complex.
- Crash if we can't allocate memory. That has been rejected in other ca= ses.

>
> Btw, the non_local_exit_get function is currently not documented in > the ELisp manual; should it be?

At least in Emacs 29 I see it documented ("Module Nonlocal" node)= .


--
Google Germany GmbH
Erika-Mann-Stra=C3=9Fe 33
80636 M=C3=BCnchen

Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls Sie diese f=C3=A4lschlicherweise
erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes
weiter, l=C3=B6schen Sie alle Kopien und Anh=C3=A4nge davon und lassen Sie = mich
bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by
mistake, please don=E2=80=99t forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the
wrong person.
--00000000000087d0b2062cdbfae2-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 09:43:36 2025 Received: (at 65796) by debbugs.gnu.org; 25 Feb 2025 14:43:36 +0000 Received: from localhost ([127.0.0.1]:45531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tmw9n-0002PG-V8 for submit@debbugs.gnu.org; Tue, 25 Feb 2025 09:43:36 -0500 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:38308) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tmw9k-0002Ov-6u for 65796@debbugs.gnu.org; Tue, 25 Feb 2025 09:43:33 -0500 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-5dc191ca8baso1383531a12.1 for <65796@debbugs.gnu.org>; Tue, 25 Feb 2025 06:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740494606; x=1741099406; darn=debbugs.gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=YSj/WJe4wCcaAeKnkTJ0byjGADgMEml+hk2AlQ/peqA=; b=UYtZcSTWOaIAtHRh40bofYgqeYsJC4KLjB7yTzDY5L2UyYSgujkcHLcVF+nEp+ZcpZ 9T1X8er2unT9fhRDBOO5K+o7XB9ydmvhiYQpbcnZO7Fz+3YBAUU3IyvJiflWTsrhWN5Z QgvjYp2LYdMS5C2Xm3264rkSh4ctvBO8EZwYAHU7qJff8ddrkUsfje9LzBVjG4GzQorz XIONHJgfTIyZS/aoF5ZmZ/gf+SBU7wEFJrRiuDbm3J0oJT99teapDPmcwa+Uw7eGDwp0 pjWJ4BmZf6IGmAPiSNf0MU0FuuAU+BRPCrSQjuUFL0yHZuo+yecRCTISX/Cjfd4v3nNp Qe/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740494606; x=1741099406; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YSj/WJe4wCcaAeKnkTJ0byjGADgMEml+hk2AlQ/peqA=; b=WZmP2FONihTQ476SV9MyykrQnH+ZBNe2Bj738OukZArxWmIFPLZhtVMwPskAKWav0a Vn/lEB0yc4c8SCmwWE6yFjqjofrm9Bj/dV94v+mqyLRonPtfFmHEIUSePgvQ8YuRmqZk qYF19vdXi8tm58LUr8nkFDP+OAvxUV4aRh+H+dFSp9dRUjgTCWcGtJLaicqcAbprg3yd yawsklnsjCuFkeD+ccSQSk4Eu9nCIwXauKcN3y9PB9lW6XlSNL+Ll13/ttTVAfUF/PJo mPkGrp2AwDkaD8Dfznzq51lidxT3HfcRMT57opKH6ym1Hx2ism7WjOqZOgUyGvzZwVOL iyyA== X-Forwarded-Encrypted: i=1; AJvYcCXf6rgAhMQ2rtJByZM0N7lm0aJhaecuF3aNDTMK4R6lqfs6kfjaewEcFw5TVSkTcXs5aJDgSg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxW4VNJD/e71lyo0dUewXlWHSyhApYTYZz9lWylO4NwEfUFaGYv Ea3MASfzg9h6dJP/0wFg2vSG5YKCZ2WLzp8bvJ1cLspszRPBn7tI X-Gm-Gg: ASbGnctcTuSNUYmG3S8Pad/PGRBN1T9u3HEsOv5BYsF2Ne/37LiDsPrGkjEbSRnwurQ KmMNuEhMTLQlYMFQENkSxGdgx+OByMuHp7umavgXHCzhqgmZ1coHG6Wp4TLDkKAOeQRwTpCjLS/ mOpwEKNTJgr5Tl5NjP+X+EbLOTlYxiTu0cdHV/MjoYyZDLvagBxXLZTomuVUcXDAsSX49HNRBqu xZNIOmuvlVeEHMHbsRYvEjFvJNqS/dtniy/4lVWsHEhBDArpjo0BHZixhG5ozeN8apPEG9ZnROJ hq/PAbuDY7QVaEl+vOcjb3VJWryLhNHCw0EgHgO38QZWx438ucqiROit X-Google-Smtp-Source: AGHT+IEUprmnwKKLZGVIoQqQOTvV5hI21ySppO+ysAb6MJ8/6JNRk13HI9ZScpwz1CHJuyJjqs/H/Q== X-Received: by 2002:a05:6402:2551:b0:5e0:7afe:4e12 with SMTP id 4fb4d7f45d1cf-5e0b724c6f8mr6610225a12.10.1740494605566; Tue, 25 Feb 2025 06:43:25 -0800 (PST) Received: from smtpclient.apple ([2001:a61:3a5d:f801:a9d8:55fa:e6d8:4777]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5e492120418sm898675a12.14.2025.02.25.06.43.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2025 06:43:24 -0800 (PST) From: Philipp Stephani Message-Id: <23B6FA1A-CFCD-43DD-B425-AC236990335C@gmail.com> Content-Type: multipart/mixed; boundary="Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals Date: Tue, 25 Feb 2025 15:43:13 +0100 In-Reply-To: To: Xinyang Chen References: <8334zq1mx6.fsf@gnu.org> X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 65796 Cc: Philipp Stephani , Eli Zaretskii , Daniel Colascione , 65796@debbugs.gnu.org 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.7 (/) --Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 29.01.2025 um 18:52 schrieb Xinyang Chen : >=20 > This is still a problem. >=20 > Using a user buffer will require gc-protecting it and thus a major = overhaul, so I think it's not a good idea. Yeah, I figured out that approach is a dead end meanwhile. >=20 > IMO what we should do is: if we fail to allocate, we discard the = original signal and replace it with an OOM signal (pointing to constants = so requiring no allocation). Yeah, that's a good idea, thanks for bringing it up. I've attached a = patch to that effect. > Perhaps we should make a new field in emacs_funcall_exit for OOM, or = we can just use emacs_funcall_exit_signal. My patch does the latter: Adding a new enum value risks UB if callers = don't have a default case in their switch statements, behavior in OOM = situations is best-effort anyway, and very careful callers can still = compare the returned error symbol against the (documented) OOM symbol. >=20 > Alternatively, make a copy_emacs_value function that allows the user = to copy the signal out, returning NULL to let the caller know that an = allocation failure occurred. I also considered that, but it puts too much onus on the module authors = to deal with a situation that effectively never happens. >=20 >=20 >=20 > On Thu, Sep 7, 2023 at 5:24=E2=80=AFAM Philipp Stephani = wrote: > On Thu, 7 Sept 2023 at 09:07, Eli Zaretskii wrote: > > > > > From: Xinyang Chen > > > Date: Wed, 6 Sep 2023 18:52:14 -0400 > > > > > > Currently `module_non_local_exit_get` returns pointers to fields > > > in emacs_env_private: > > > ``` > > > if (p->pending_non_local_exit !=3D emacs_funcall_exit_return) > > > { > > > *symbol =3D &p->non_local_exit_symbol; > > > *data =3D &p->non_local_exit_data; > > > } > > > ``` > > > this means that if one tries to: > > > ``` > > > funcall(...); > > > non_local_exit_get(&s1, &d1); > > > funcall(...); > > > non_local_exit_get(&s2, &d2); > > > non_local_exit_signal(s1, d1); > > > ``` > > > you would signal the second error, instead of the first error (I = expected > > > this to happen). > > > It seems to me that `module_non_local_exit_get` should > > > `allocate_emacs_value` instead. > > > > Philipp, Daniel: any comments? >=20 > Nice find! > We can't use allocate_emacs_value here because non_local_exit_get has > to work in OOM situations and can never fail. What we could do here is > e.g.: > - Document the current behavior, stating that the emacs_value objects > returned from non_local_exit_get are ephemeral. I'm not a huge fan of > this because it makes non_local_exit_get behave different from all > other functions. > - Provide an alternative non_local_exit_copy that copies the 2 > Lisp_Objects into an opaque buffer supplied by the user (plus a way to > determine the buffer size). That way we shift the responsibility of > dealing with allocation failures to the user. > - Attempt to allocate a new emacs_value, fall back to the current > behavior if that fails. I don't really like that option either because > it doesn't solve the initial problem in all cases (so users still need > to deal with it), but makes both the interface and the implementation > more complex. > - Crash if we can't allocate memory. That has been rejected in other = cases. >=20 > > > > Btw, the non_local_exit_get function is currently not documented in > > the ELisp manual; should it be? >=20 > At least in Emacs 29 I see it documented ("Module Nonlocal" node). --Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8 Content-Disposition: attachment; filename=0001-Don-t-overwrite-non-local-exit-symbol-and-data-Bug-6.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="0001-Don-t-overwrite-non-local-exit-symbol-and-data-Bug-6.patch" Content-Transfer-Encoding: quoted-printable =46rom=203f3cf20a405a299232be394aed304d37ef80a68c=20Mon=20Sep=2017=20= 00:00:00=202001=0AFrom:=20Philipp=20Stephani=20=0A= Date:=20Thu,=2030=20Jan=202025=2016:12:49=20+0100=0ASubject:=20[PATCH]=20= Don't=20overwrite=20non-local=20exit=20symbol=20and=20data=20= (Bug#65796).=0A=0AThe=20previous=20approach=20would=20incorrectly=20= invalidate=20the=20returned=20module=0Avalues=20if=20another=20non-local=20= exit=20occurred=20while=20dealing=20with=20a=20non-local=0Aexit.=20=20= See=20Bug#65796.=20=20Instead,=20allocate=20the=20values=20from=20the=20= usual=0Aenvironment=20storage,=20and=20return=20statically-allocated=20= objects=20if=20that=0Afails.=0A=0A*=20src/emacs-module.c=20(struct=20= emacs_env_private):=20Turn=20non-local=20exit=0Asymbol=20and=20data=20= into=20normal=20Lisp=20objects.=0A(initialize_environment):=20Initialize=20= them.=0A(mark_module_environment):=20Prevent=20them=20from=20being=20= garbage-collected.=0A(module_signal_or_throw,=20= module_non_local_exit_signal_1)=0A(module_non_local_exit_throw_1):=20= Adapt=20uses.=0A(value_to_lisp):=20No=20longer=20scan=20for=20them=20= with=20module=20assertions=20enabled.=0A(module_out_of_memory_signal,=20= module_out_of_memory_data):=20New=0Astatically-allocated=20module=20= values=20to=20return=20in=20case=20of=20allocation=0Afailure.=0A= (syms_of_module):=20Initialize=20them.=0A(module_non_local_exit_get):=20= Allocate=20module=20values=20normally.=20=20If=20that=0Afails,=20return=20= statically-allocated=20values.=0A=0A*=20doc/lispref/internals.texi=20= (Module=20Nonlocal):=20Document=20new=20behavior.=0A---=0A=20= doc/lispref/internals.texi=20|=20=206=20+++-=0A=20src/emacs-module.c=20=20= =20=20=20=20=20=20=20|=2063=20++++++++++++++++++++++++++------------=0A=20= 2=20files=20changed,=2048=20insertions(+),=2021=20deletions(-)=0A=0Adiff=20= --git=20a/doc/lispref/internals.texi=20b/doc/lispref/internals.texi=0A= index=20ee1fcbbbd68..a8b9ea88f7f=20100644=0A---=20= a/doc/lispref/internals.texi=0A+++=20b/doc/lispref/internals.texi=0A@@=20= -2076,7=20+2076,11=20@@=20Module=20Nonlocal=0A=20tag=20symbol=20in=20= @code{*@var{symbol}}=20and=20the=20@code{throw}=20value=20in=0A=20= @code{*@var{data}}.=20=20The=20function=20doesn't=20store=20anything=20= in=20memory=0A=20pointed=20by=20these=20arguments=20when=20the=20return=20= value=20is=0A-@code{emacs_funcall_exit_return}.=0A= +@code{emacs_funcall_exit_return}.=20=20If=20the=20function=20fails=20to=20= allocate=0A+storage=20for=20@var{symbol}=20or=20@var{data},=20it=20= stores=20a=20value=20representing=0A+the=20symbol=20= @code{module-out-of-memory}=20in=20@code{*@var{symbol}},=20stores=20a=0A= +value=20representing=20@code{nil}=20in=20@code{*@var{data}},=20and=20= returns=0A+@code{emacs_funcall_exit_signal}.=0A=20@end=20deftypefn=0A=20=0A= =20You=20should=20check=20nonlocal=20exit=20conditions=20where=20it=20= matters:=20before=20you=0Adiff=20--git=20a/src/emacs-module.c=20= b/src/emacs-module.c=0Aindex=200a67433ec70..ab6b900df8d=20100644=0A---=20= a/src/emacs-module.c=0A+++=20b/src/emacs-module.c=0A@@=20-167,7=20+167,7=20= @@=20Copyright=20(C)=202015-2025=20Free=20Software=20Foundation,=20Inc.=0A= =20=20=20/*=20Dedicated=20storage=20for=20non-local=20exit=20symbol=20= and=20data=20so=20that=0A=20=20=20=20=20=20storage=20is=20always=20= available=20for=20them,=20even=20in=20an=20out-of-memory=0A=20=20=20=20=20= =20situation.=20=20*/=0A-=20=20struct=20emacs_value_tag=20= non_local_exit_symbol,=20non_local_exit_data;=0A+=20=20Lisp_Object=20= non_local_exit_symbol,=20non_local_exit_data;=0A=20=0A=20=20=20struct=20= emacs_value_storage=20storage;=0A=20};=0A@@=20-500,6=20+500,9=20@@=20= module_non_local_exit_clear=20(emacs_env=20*env)=0A=20=20=20= env->private_members->pending_non_local_exit=20=3D=20= emacs_funcall_exit_return;=0A=20}=0A=20=0A+static=20struct=20= emacs_value_tag=20module_out_of_memory_symbol;=0A+static=20struct=20= emacs_value_tag=20module_out_of_memory_data;=0A+=0A=20static=20enum=20= emacs_funcall_exit=0A=20module_non_local_exit_get=20(emacs_env=20*env,=0A= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20emacs_value=20*symbol,=20emacs_value=20*data)=0A@@=20-507,12=20= +510,23=20@@=20module_non_local_exit_get=20(emacs_env=20*env,=0A=20=20=20= module_assert_thread=20();=0A=20=20=20module_assert_env=20(env);=0A=20=20= =20struct=20emacs_env_private=20*p=20=3D=20env->private_members;=0A-=20=20= if=20(p->pending_non_local_exit=20!=3D=20emacs_funcall_exit_return)=0A+=20= =20enum=20emacs_funcall_exit=20ret=20=3D=20p->pending_non_local_exit;=0A= +=20=20if=20(ret=20!=3D=20emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A= -=20=20=20=20=20=20*symbol=20=3D=20&p->non_local_exit_symbol;=0A-=20=20=20= =20=20=20*data=20=3D=20&p->non_local_exit_data;=0A+=20=20=20=20=20=20= emacs_value=20sym=0A+=09=3D=20allocate_emacs_value=20(env,=20= p->non_local_exit_symbol);=0A+=20=20=20=20=20=20emacs_value=20dat=0A+=09= =3D=20allocate_emacs_value=20(env,=20p->non_local_exit_data);=0A+=20=20=20= =20=20=20if=20(sym=20=3D=3D=20NULL=20||=20dat=20=3D=3D=20NULL)=0A+=09{=0A= +=09=20=20sym=20=3D=20&module_out_of_memory_symbol;=0A+=09=20=20dat=20=3D=20= &module_out_of_memory_data;=0A+=09=20=20ret=20=3D=20= emacs_funcall_exit_signal;=0A+=09}=0A+=20=20=20=20=20=20*symbol=20=3D=20= sym;=0A+=20=20=20=20=20=20*data=20=3D=20dat;=0A=20=20=20=20=20}=0A-=20=20= return=20p->pending_non_local_exit;=0A+=20=20return=20ret;=0A=20}=0A=20=0A= =20/*=20Like=20for=20`signal',=20DATA=20must=20be=20a=20list.=20=20*/=0A= @@=20-1185,11=20+1199,11=20@@=20module_signal_or_throw=20(struct=20= emacs_env_private=20*env)=0A=20=20=20=20=20case=20= emacs_funcall_exit_return:=0A=20=20=20=20=20=20=20return;=0A=20=20=20=20=20= case=20emacs_funcall_exit_signal:=0A-=20=20=20=20=20=20xsignal=20= (value_to_lisp=20(&env->non_local_exit_symbol),=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20value_to_lisp=20(&env->non_local_exit_data));=0A+=20= =20=20=20=20=20xsignal=20(env->non_local_exit_symbol,=0A+=09=20=20=20=20=20= =20=20env->non_local_exit_data);=0A=20=20=20=20=20case=20= emacs_funcall_exit_throw:=0A-=20=20=20=20=20=20Fthrow=20(value_to_lisp=20= (&env->non_local_exit_symbol),=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20= =20value_to_lisp=20(&env->non_local_exit_data));=0A+=20=20=20=20=20=20= Fthrow=20(env->non_local_exit_symbol,=0A+=09=20=20=20=20=20=20= env->non_local_exit_data);=0A=20=20=20=20=20default:=0A=20=20=20=20=20=20= =20eassume=20(false);=0A=20=20=20=20=20}=0A@@=20-1389,8=20+1403,8=20@@=20= module_non_local_exit_signal_1=20(emacs_env=20*env,=20Lisp_Object=20sym,=0A= =20=20=20if=20(p->pending_non_local_exit=20=3D=3D=20= emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A=20=20=20=20=20=20=20= p->pending_non_local_exit=20=3D=20emacs_funcall_exit_signal;=0A-=20=20=20= =20=20=20p->non_local_exit_symbol.v=20=3D=20sym;=0A-=20=20=20=20=20=20= p->non_local_exit_data.v=20=3D=20data;=0A+=20=20=20=20=20=20= p->non_local_exit_symbol=20=3D=20sym;=0A+=20=20=20=20=20=20= p->non_local_exit_data=20=3D=20data;=0A=20=20=20=20=20}=0A=20}=0A=20=0A= @@=20-1402,8=20+1416,8=20@@=20module_non_local_exit_throw_1=20(emacs_env=20= *env,=20Lisp_Object=20tag,=0A=20=20=20if=20(p->pending_non_local_exit=20= =3D=3D=20emacs_funcall_exit_return)=0A=20=20=20=20=20{=0A=20=20=20=20=20=20= =20p->pending_non_local_exit=20=3D=20emacs_funcall_exit_throw;=0A-=20=20=20= =20=20=20p->non_local_exit_symbol.v=20=3D=20tag;=0A-=20=20=20=20=20=20= p->non_local_exit_data.v=20=3D=20value;=0A+=20=20=20=20=20=20= p->non_local_exit_symbol=20=3D=20tag;=0A+=20=20=20=20=20=20= p->non_local_exit_data=20=3D=20value;=0A=20=20=20=20=20}=0A=20}=0A=20=0A= @@=20-1439,13=20+1453,6=20@@=20value_to_lisp=20(emacs_value=20v)=0A=20=20= =20=20=20=20=20=20=20=20=20{=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= const=20emacs_env=20*env=20=3D=20pdl->unwind_ptr.arg;=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20struct=20emacs_env_private=20*priv=20=3D=20= env->private_members;=0A-=20=20=20=20=20=20=20=20=20=20=20=20/*=20The=20= value=20might=20be=20one=20of=20the=20nonlocal=20exit=20values.=20=20= Note=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20that=20we=20don't=20= check=20whether=20a=20nonlocal=20exit=20is=20currently=0A-=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20pending,=20because=20the=20module=20might=20= have=20cleared=20the=20flag=0A-=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20in=20the=20meantime.=20=20*/=0A-=20=20=20=20=20=20=20=20=20=20=20=20= if=20(&priv->non_local_exit_symbol=20=3D=3D=20v=0A-=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20||=20&priv->non_local_exit_data=20=3D=3D=20v)=0A= -=20=20=20=20=20=20=20=20=20=20=20=20=20=20goto=20ok;=0A=20=20=20=20=20=20= =20=20=20=20=20=20=20if=20(value_storage_contains_p=20(&priv->storage,=20= v,=20&num_values))=0A=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20goto=20= ok;=0A=20=20=20=20=20=20=20=20=20=20=20=20=20++num_environments;=0A@@=20= -1536,6=20+1543,8=20@@=20mark_module_environment=20(void=20*ptr)=0A=20{=0A= =20=20=20emacs_env=20*env=20=3D=20ptr;=0A=20=20=20struct=20= emacs_env_private=20*priv=20=3D=20env->private_members;=0A+=20=20= mark_object=20(priv->non_local_exit_symbol);=0A+=20=20mark_object=20= (priv->non_local_exit_data);=0A=20=20=20for=20(struct=20= emacs_value_frame=20*frame=20=3D=20&priv->storage.initial;=20frame=20!=3D=20= NULL;=0A=20=20=20=20=20=20=20=20frame=20=3D=20frame->next)=0A=20=20=20=20= =20for=20(int=20i=20=3D=200;=20i=20<=20frame->offset;=20++i)=0A@@=20= -1561,6=20+1570,8=20@@=20initialize_environment=20(emacs_env=20*env,=20= struct=20emacs_env_private=20*priv)=0A=20=20=20=20=20}=0A=20=0A=20=20=20= priv->pending_non_local_exit=20=3D=20emacs_funcall_exit_return;=0A+=20=20= priv->non_local_exit_symbol=20=3D=20Qnil;=0A+=20=20= priv->non_local_exit_data=20=3D=20Qnil;=0A=20=20=20initialize_storage=20= (&priv->storage);=0A=20=20=20env->size=20=3D=20sizeof=20*env;=0A=20=20=20= env->private_members=20=3D=20priv;=0A@@=20-1711,6=20+1722,18=20@@=20= syms_of_module=20(void)=0A=20=20=20Vmodule_refs_hash=0A=20=20=20=20=20=3D=20= make_hash_table=20(&hashtest_eq,=20DEFAULT_HASH_SIZE,=20Weak_None);=0A=20= =0A+=20=20DEFSYM=20(Qmodule_out_of_memory,=20"module-out-of-memory");=0A= +=20=20Fput=20(Qmodule_out_of_memory,=20Qerror_conditions,=0A+=09list2=20= (Qmodule_out_of_memory,=20Qerror));=0A+=20=20Fput=20= (Qmodule_out_of_memory,=20Qerror_message,=0A+=09build_unibyte_string=20= ("Module=20out=20of=20memory"));=0A+=0A+=20=20staticpro=20= (&module_out_of_memory_symbol.v);=0A+=20=20module_out_of_memory_symbol.v=20= =3D=20Qmodule_out_of_memory;=0A+=0A+=20=20staticpro=20= (&module_out_of_memory_data.v);=0A+=20=20module_out_of_memory_data.v=20=3D= =20Qnil;=0A+=0A=20=20=20DEFSYM=20(Qmodule_load_failed,=20= "module-load-failed");=0A=20=20=20Fput=20(Qmodule_load_failed,=20= Qerror_conditions,=0A=20=09list=20(Qmodule_load_failed,=20Qerror));=0A--=20= =0A2.39.5=20(Apple=20Git-154)=0A=0A= --Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_19C77EA4-DF56-4F6A-838F-A39D1668C8F8-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 25 18:25:59 2025 Received: (at control) by debbugs.gnu.org; 25 Feb 2025 23:26:00 +0000 Received: from localhost ([127.0.0.1]:49029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tn4JL-0000xp-LK for submit@debbugs.gnu.org; Tue, 25 Feb 2025 18:25:59 -0500 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:59728) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tn4JJ-0000xa-8A for control@debbugs.gnu.org; Tue, 25 Feb 2025 18:25:57 -0500 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5ded51d31f1so11068101a12.3 for ; Tue, 25 Feb 2025 15:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740525951; x=1741130751; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=fvq2T+RmPSN+uNCPeJq5/8s3Jj2sTxDjulLlvSWskzk=; b=R69Wwl/0XLw23qBwDlJqmAmy1SipTnTKtYtuv6O0tGWvnKZH+LqRFPrCPR4Brw2gKY 14OchPB3r+340lMiazpY4Jehj8Giu5FF3ecSnLualXyYOykjGM3Wg1Fb7AQ57LPYfQxP UQ48muziK68jSGDc8mtUuAUJ6eCaHgMcQ/iwIi0BuQod3+ZodKmQya3CyK5HTSZ//gc+ plg0Fw24aYsvz0VX+Iod2gdZylw4LYKh/QQys8F9hbJxCI1Vo722tmev+JhdhbYBXwQS QI40+lbDOHfZjxxnc6e4+A1oVjx7H/oBDA0+l2ylXRRbO/GiGaSM1jO4r3EaSJP9dWeq gpnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740525951; x=1741130751; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fvq2T+RmPSN+uNCPeJq5/8s3Jj2sTxDjulLlvSWskzk=; b=oTT0UkBfOP/u0ISbDALb9DPyAw3HN/IBnPei6pNT143KuhcJP0bkE+DXmXGVek+XfK OfRvJd1Ga0e5t8Yq84o1pxDh9H2+APAmTnLA8UI4zQKjNNyio2rpXy9QpC14yuD3qTYS PjHSP2xzmTn1sj9YuqY1pPA/VP/uL+l3hHsej2M6BIgWHuvChqP+S0Qo0E92r6D7YgCh YfOEmZUE6gugpEWV+Bun4e9c5H6Pc9N/sAX4p9RBr6tLvCPSsV5vmOZjrQj7ryUJHRp8 abnDyhqQxcjGXJHz+soT8KOLHJHt2R72K9+0p6UBlLG0uZJWkftOmlysTofjkMsvT2n9 4ETQ== X-Gm-Message-State: AOJu0YyjNS6oDyu/Hi06N20c76XXQzzlBlDk0sTaUmjgDhDnGszw87US YaRLWFkydCN9uTSXOqV8Hs+jJ0lfS2rz8szWd6BATFz338iFcBBG84+j49UuCXbmydFDsSlstcv yKTC0uLw2sehCkpbpFPc9bhIcj1XRaTNjVeY= X-Gm-Gg: ASbGncuAn8eQoYfnBhBjlY4jpB9cJRf5NQ1hZTCuDbcDBKKNgB96yXBHvlQsU5cO4yR ISjHF5jSrhPf7ZKiLhYKKrmq/h2k2tyIp6pKxc9kVzbaegLLzxIOPYSqLRk1r7QeThRz0JOj9xQ QdSMOoHFE= X-Google-Smtp-Source: AGHT+IEpNtqIcChyyYv6Itr9iN9P3cSLwYM9IM2m5G2LdByxHzDjtvJGmkXzFpddItSEu09M5g4EvT8vPh+lxGyMALM= X-Received: by 2002:a05:6402:35d1:b0:5e0:750a:5c30 with SMTP id 4fb4d7f45d1cf-5e4a0dfc708mr1598164a12.20.1740525950469; Tue, 25 Feb 2025 15:25:50 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Feb 2025 23:25:50 +0000 From: Stefan Kangas MIME-Version: 1.0 Date: Tue, 25 Feb 2025 23:25:50 +0000 X-Gm-Features: AQ5f1Jqx_7znwSJJNoCnpwHXJgW8AyjR9JnglV6WpoRcwL9vA-_3fw47SVgOhIk Message-ID: Subject: control message for bug #65796 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control 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 (-) tags 65796 + patch quit From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 27 20:15:27 2025 Received: (at 65796-done) by debbugs.gnu.org; 28 Feb 2025 01:15:27 +0000 Received: from localhost ([127.0.0.1]:40851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tnoyM-0004BN-Ti for submit@debbugs.gnu.org; Thu, 27 Feb 2025 20:15:27 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:40527) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tnoyK-00045q-7L for 65796-done@debbugs.gnu.org; Thu, 27 Feb 2025 20:15:25 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5dc050e6a9dso292840a12.2 for <65796-done@debbugs.gnu.org>; Thu, 27 Feb 2025 17:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740705318; x=1741310118; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CCmkFQDC02MAYmyjLRB8hx0EGMRtmr2iP1Zf9bBYPKQ=; b=QYQqEJl0Uv4ta5EKfI7O8mPn++eL84ANT0u0Tr7FawiBYtkkAJf8cgkDfEnN5UEqLq qGPH/eNP+BuVufE4CKDCpZSDjEh7YIPk9we5eDIMKp84uaH2wGIygMp0L0LuAffZsTKt WbTpzEqPwBZ38shNv8wFP6HuUdfZ6NV5prQ4grF2+YwFmE1q/Z8SvksGxWli98waYPFg GSl/5qCg/IOwiYeQzvHsLafJvqlBR8QkhIPW9jxW1wQmMK+3kRd23lZ6xRws1kmOFnpO vImP9UhHHApvHiReeQbWiePcpKQXBUTJARGVHxxZAKaf9lv5tMYEylA05ae6RkqXV1yq K/ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740705318; x=1741310118; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CCmkFQDC02MAYmyjLRB8hx0EGMRtmr2iP1Zf9bBYPKQ=; b=Xt1ypz/1jR4UOCb+hcppzed8l+srFGTnXkV9PTQLor9wsLbL13h4lvS+YB4MVxnVB0 g/w5AU92cWghHY+tH7ZdfXYag0LrjJbvcyKmfOATbA3HAQm/7sH6U+lie9z9uQHdPyDL TZDvJtFTpcJOgRMv7hk34i3hB87UKM2ML16ZFAOUzL15R9UQ4YpsvhTyLrU5LV84hgQo Gg1ayPpbtL+R4/VwdgQl6ar0sQA/Th2NE5sCiTBo9g6NfGB/sP52kgFsSLJxDzAa+Q71 iTSbzKJFV3mx6ARyuUNcuoRABBb6jCwx8nCDzcUrLc0hyeK62HUCnBNUPgzm9CnSu7QV Rlzw== X-Forwarded-Encrypted: i=1; AJvYcCWLwC+1qdPVo5c4mLmlcOZIWplyNvvbmXaaLZrUdcCFCpPEnQhtn5n8PpW+WJokmxOyPqCIy6QGE2nG@debbugs.gnu.org X-Gm-Message-State: AOJu0YxomDjZBo1y3CVp+vF1fiEu4utSJtNomzlPNEFhmfQrkSEBmM6E 8jN3HBTJo0wDi7YwFGHZjNFHkRjEC6DgApZ/riXaoynCeWU8Ckoa X-Gm-Gg: ASbGnctTp1czKUoyGuZ3MYhI/ejaUwx+vd/NZvXpIODIP4oVZ0IG8dPgkG5YwDsFCRA Vz6Pka7OP5MdNB4xuNZw9Jz99q7kp3sY95VZEmDswUCmxS0i9T3ta+bkHOmdix5cYg/rn3d3V+H D2k4ap8DC8TnVFBcR6RaN34bQWrBu5iL3bJWEYLCFuZeV68fNFqEVqa+02OS+k70RmZaP46S/cY 8JX8GzFqehr2Y6n3Dw2EdwL5A0U7STa3ldbBABbyodVN5qf1zFZ3TI4YB3VwOqQtgW6/qY1GThj wnA8YB5L5FrOqAOK2CajYa1IbhiqM2/DtiaF5+Yws0eWJyG9bkSw1WQ= X-Google-Smtp-Source: AGHT+IHrp0SOjSmwxPM+siWcLpjT4fUD+wiSZ3pKI7VcLDlq5hGjvAhcp0J79hZ9g10GQqRru+7L1w== X-Received: by 2002:a17:907:868a:b0:aa6:9574:1728 with SMTP id a640c23a62f3a-abf261e600emr58278666b.6.1740705317712; Thu, 27 Feb 2025 17:15:17 -0800 (PST) Received: from smtpclient.apple ([2001:a61:3a3d:b01:b421:c261:64a9:4e87]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-abf0c0ba6b5sm203455266b.30.2025.02.27.17.15.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2025 17:15:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\)) Subject: Re: bug#65796: dynamic module non_local_exit_get overwrites exit signals From: Philipp Stephani In-Reply-To: <23B6FA1A-CFCD-43DD-B425-AC236990335C@gmail.com> Date: Fri, 28 Feb 2025 02:15:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <36742586-18AD-4633-B917-0B0A25875AAE@gmail.com> References: <8334zq1mx6.fsf@gnu.org> <23B6FA1A-CFCD-43DD-B425-AC236990335C@gmail.com> To: Xinyang Chen X-Mailer: Apple Mail (2.3826.400.131.1.6) X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 65796-done Cc: Philipp Stephani , Eli Zaretskii , Daniel Colascione , 65796-done@debbugs.gnu.org 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.7 (/) > Am 25.02.2025 um 15:43 schrieb Philipp Stephani = : >=20 >>=20 >> IMO what we should do is: if we fail to allocate, we discard the = original signal and replace it with an OOM signal (pointing to constants = so requiring no allocation). >=20 > Yeah, that's a good idea, thanks for bringing it up. I've attached a = patch to that effect. Pushed as commit 32da093e524d5e28945557701f7c50d7c4a898cd. From unknown Mon Jun 23 02:22:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 28 Mar 2025 11:24:17 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator