From unknown Fri Aug 15 12:50:54 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#75754 <75754@debbugs.gnu.org> To: bug#75754 <75754@debbugs.gnu.org> Subject: Status: styled_format stack usage/GC protection Reply-To: bug#75754 <75754@debbugs.gnu.org> Date: Fri, 15 Aug 2025 19:50:54 +0000 retitle 75754 styled_format stack usage/GC protection reassign 75754 emacs submitter 75754 Pip Cet severity 75754 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 05:19:03 2025 Received: (at submit) by debbugs.gnu.org; 22 Jan 2025 10:19:03 +0000 Received: from localhost ([127.0.0.1]:60008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1taXp9-0007ud-1m for submit@debbugs.gnu.org; Wed, 22 Jan 2025 05:19:03 -0500 Received: from lists.gnu.org ([2001:470:142::17]:58394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1taXp5-0007u8-U8 for submit@debbugs.gnu.org; Wed, 22 Jan 2025 05:19:00 -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 1taXp0-0007da-JJ for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2025 05:18:54 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1taXoy-0002qS-3m for bug-gnu-emacs@gnu.org; Wed, 22 Jan 2025 05:18:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737541128; x=1737800328; bh=gRDpPvIUzmw1IPb6KvBR5I7qTbagOs1Ne12B9ROlems=; 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=rD5aPHdgZqdDEzKa/hMRrlzDiK2TTyF60TZ1qDSRNw83VEp4g2Jk1anLzfa212V9C uwE/tgzlToUYzIV+ZkTS4J0mq+PVaexdUmg4XQh9c1NKReTdMu6YaJ2dasOe6hIIMl 3KUd12EHxYFOESDlYDcVoxqSiNuQgxbeJcj2n86Bqy7p3C9L92Q61G9Hwo8H960U36 Jl7a8elFIIPx9zp1+uw/YTYkCt5BaqCqCRipHltRHYqC0T5mumEkoTOo84d2pwao3w mKrbdpb93S50Xe2vNQuuf7qz4kcoBsrfFKqx2BuPqAu7P31St1giDlSCf4Dc62UjBL mz2MmORl294CA== Date: Wed, 22 Jan 2025 10:18:32 +0000 To: bug-gnu-emacs@gnu.org, Paul Eggert From: Pip Cet Subject: styled_format stack usage/GC protection Message-ID: <87sepbdudr.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: ed894b316029f554798f964ba072d6c26d1485cc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 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_H2=-0.086, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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-Debbugs-Envelope-To: submit 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 (/) This popped up while trying to debug the feature/igc branch and looking into formatted output functions to replace sprintf/snprintf: The function styled_format in editfns.c does this: enum { /* Maximum precision for a %f conversion such that the trailing output digit might be nonzero. Any precision larger than this will not yield useful information. */ USEFUL_PRECISION_MAX =3D ((1 - LDBL_MIN_EXP) =09=09=09 * (FLT_RADIX =3D=3D 2 || FLT_RADIX =3D=3D 10 ? 1 =09=09=09 : FLT_RADIX =3D=3D 16 ? 4 =09=09=09 : -1)), /* Maximum number of bytes (including terminating null) generated by any format, if precision is no more than USEFUL_PRECISION_MAX. On all practical hosts, %Lf is the worst case. */ SPRINTF_BUFSIZE =3D (sizeof "-." + (LDBL_MAX_10_EXP + 1) =09=09 + USEFUL_PRECISION_MAX) }; char initial_buffer[1000 + SPRINTF_BUFSIZE]; USE_SAFE_ALLOCA; sa_avail -=3D sizeof initial_buffer; On my system, the relevant values are: USEFUL_PRECISION_MAX 16382 SPRINTF_BUFSIZE 21318 MAX_ALLOCA 16384 After the code above executes, sa_avail is -5934. styled_format proceeds to allocate a structure using SAFE_ALLOCA: /* Information recorded for each format spec. */ struct info { /* The corresponding argument, converted to string if conversion was needed. */ Lisp_Object argument; /* The start and end bytepos in the output string. */ ptrdiff_t start, end; /* The start bytepos of the spec in the format string. */ ptrdiff_t fbeg; /* Whether the argument is a string with intervals. */ bool_bf intervals : 1; } *info; info =3D SAFE_ALLOCA (alloca_size); While the alloca_size value is small, sa_avail is negative when we enter SAFE_ALLOCA, so SAFE_ALLOCA uses xmalloc to allocate the memory on the heap. The structure contains a Lisp_Object. This Lisp_Object must be protected from GC by being present on the C stack if GC can ever happen in this function. SAFE_ALLOCA doesn't protect it. I'm not entirely sure this is a problem, but (let ((print-unreadable-function (lambda (&rest args) (garbage-collect)))) (format "%S" (symbol-function '+))) produces this backtrace: #0 garbage_collect () at alloc.c:6450 #1 0x00005555557f7700 in Fgarbage_collect () at alloc.c:6697 #2 0x000055555582e1ee in eval_sub (form=3DXIL(0x7ffff4dab073)) at eval.c:2= 584 #3 0x0000555555828d9f in Fprogn (body=3DXIL(0)) at eval.c:439 #4 0x0000555555830604 in funcall_lambda (fun=3DXIL(0x555556045c9d), nargs= =3D2, arg_vector=3D0x7fffffff6b78) at eval.c:3339 #5 0x000055555582f62d in funcall_general (fun=3DXIL(0x555556045c9d), numar= gs=3D2, args=3D0x7fffffff6b78) at eval.c:3033 #6 0x000055555582f89a in Ffuncall (nargs=3D3, args=3D0x7fffffff6b70) at ev= al.c:3082 #7 0x0000555555863e8a in print_vectorlike_unreadable (obj=3DXIL(0x555555ee7765), printcharfun=3DXIL(0), escapeflag=3Dtrue, b= uf=3D0x7fffffff6ce0 "\220m\377\377\377\177") at print.c:1683 #8 0x0000555555866e5f in print_object (obj=3DXIL(0x555555ee7765), printcha= rfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2647 #9 0x0000555555862ec2 in print (obj=3DXIL(0x555555ee7765), printcharfun=3D= XIL(0), escapeflag=3Dtrue) at print.c:1296 #10 0x0000555555861cef in Fprin1_to_string (object=3DXIL(0x555555ee7765), n= oescape=3DXIL(0), overrides=3DXIL(0)) at print.c:814 #11 0x000055555581fd14 in styled_format (nargs=3D2, args=3D0x7fffffffca20, = message=3Dfalse) at editfns.c:3633 #12 0x000055555581f444 in Fformat (nargs=3D2, args=3D0x7fffffffca20) at edi= tfns.c:3370 indicating that GC can happen. The code attempts to protect the current argument by keeping it in a redundant automatic variable: =09 Lisp_Object arg =3D spec->argument; ... =09 spec->argument =3D arg =3D Fprin1_to_string (arg, noescape, Qnil); I don't know whether this approach works; maybe a very smart compiler could eliminate the automatic variable and keep only the copy on the heap for some of the time, but it's unlikely that that's valid while calling GC. In any case, this protects only the current argument; if we detect a multibyte situation too late, we may restart the loop and, I think, reuse info->argument values which were unprotected during GC. The problem on the feature/igc branch may explain some of the crashes we've seen during heavy elisp usage. On the master branch, the problems are: 1. excessive stack usage: exceeding MAX_ALLOCA by creating a large temporary buffer on the stack seems unwise. 2. SAFE_ALLOCA is in use, but on many systems it's impossible to use stack space. 3. GC protection needs to be verified, or fixed if we accept that there is a possibility a Lisp_Object might be unprotected. Note that fixing (2) is strictly optional; however, fixing only (2) would make (3) a latent but still real bug, which may be worse than the current situation. On the feature/igc branch, where protection is definitely required, I'm thinking about a fix. A quick fix would be to replace all elements of struct info by Lisp_Object values and use SAFE_ALLOCA_LISP. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 10:56:23 2025 Received: (at 75754) by debbugs.gnu.org; 22 Jan 2025 15:56:23 +0000 Received: from localhost ([127.0.0.1]:36000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tad5a-0001Uq-ID for submit@debbugs.gnu.org; Wed, 22 Jan 2025 10:56:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54130) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tad5Y-0001UY-4R for 75754@debbugs.gnu.org; Wed, 22 Jan 2025 10:56:20 -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 1tad5S-0002Q4-25; Wed, 22 Jan 2025 10:56:14 -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=UGR0s93nV5Ess5WfpNHUOdFAqsBbkdAmJVoafc0E3oU=; b=SzDrElEMeNp8 W26zf+ugOl/5t90qu+a0uLxLSn7tyFBRZDKB0xAmNZrZ0XbACKuGvv62RQUzHvtm15ROzH8Vkw+lU CcGvkfgXR0814Hm3+g1jf8zFmQdGSI70xkwvxfD2XMGqQ6pSsonMXtKWo2oVdm/uJcinEvz0LJp60 1oePmCtne4IydTzVqJYxKN47h088C2tZxAZCK1j/OCqSioMy1Xebe8/K0QG7zf8eFGbqWYrjnZp3q 6gFdcMgHK0cjCyC2ad43lLo1Fw3gLv4HOOGpxpLTKL7DkmL/OPWDL9cyqgSo7Z8RXH7c+uepKd7rU X3FuzNLqHeBMVXQm5wL2Iw==; Date: Wed, 22 Jan 2025 17:56:09 +0200 Message-Id: <86ikq63krq.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87sepbdudr.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: 75754@debbugs.gnu.org, eggert@cs.ucla.edu 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: Wed, 22 Jan 2025 10:18:32 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > While the alloca_size value is small, sa_avail is negative when we enter > SAFE_ALLOCA, so SAFE_ALLOCA uses xmalloc to allocate the memory on the > heap. > > The structure contains a Lisp_Object. This Lisp_Object must be > protected from GC by being present on the C stack if GC can ever happen > in this function. SAFE_ALLOCA doesn't protect it. > > I'm not entirely sure this is a problem, but > > (let ((print-unreadable-function (lambda (&rest args) (garbage-collect)))) > (format "%S" (symbol-function '+))) > > produces this backtrace: > > #0 garbage_collect () at alloc.c:6450 > #1 0x00005555557f7700 in Fgarbage_collect () at alloc.c:6697 > #2 0x000055555582e1ee in eval_sub (form=XIL(0x7ffff4dab073)) at eval.c:2584 > #3 0x0000555555828d9f in Fprogn (body=XIL(0)) at eval.c:439 > #4 0x0000555555830604 in funcall_lambda (fun=XIL(0x555556045c9d), nargs=2, arg_vector=0x7fffffff6b78) at eval.c:3339 > #5 0x000055555582f62d in funcall_general (fun=XIL(0x555556045c9d), numargs=2, args=0x7fffffff6b78) at eval.c:3033 > #6 0x000055555582f89a in Ffuncall (nargs=3, args=0x7fffffff6b70) at eval.c:3082 > #7 0x0000555555863e8a in print_vectorlike_unreadable > (obj=XIL(0x555555ee7765), printcharfun=XIL(0), escapeflag=true, buf=0x7fffffff6ce0 "\220m\377\377\377\177") at print.c:1683 > #8 0x0000555555866e5f in print_object (obj=XIL(0x555555ee7765), printcharfun=XIL(0), escapeflag=true) at print.c:2647 > #9 0x0000555555862ec2 in print (obj=XIL(0x555555ee7765), printcharfun=XIL(0), escapeflag=true) at print.c:1296 > #10 0x0000555555861cef in Fprin1_to_string (object=XIL(0x555555ee7765), noescape=XIL(0), overrides=XIL(0)) at print.c:814 > #11 0x000055555581fd14 in styled_format (nargs=2, args=0x7fffffffca20, message=false) at editfns.c:3633 > #12 0x000055555581f444 in Fformat (nargs=2, args=0x7fffffffca20) at editfns.c:3370 > > indicating that GC can happen. > > The code attempts to protect the current argument by keeping it in a > redundant automatic variable: > > Lisp_Object arg = spec->argument; > ... > spec->argument = arg = Fprin1_to_string (arg, noescape, Qnil); I think indeed the protection here is by having the Lisp object in an automatic variable. > In any case, this protects only the current argument; if we detect a > multibyte situation too late, we may restart the loop and, I think, > reuse info->argument values which were unprotected during GC. Can you elaborate how this could happen by walking through the relevant code? > On the feature/igc branch, where protection is definitely required, I'm > thinking about a fix. A quick fix would be to replace all elements of > struct info by Lisp_Object values and use SAFE_ALLOCA_LISP. Are automatic variables not protected on the igc branch as they are with the old GC? Can we use AUTO_STRING to solve the problem? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 12:18:04 2025 Received: (at 75754) by debbugs.gnu.org; 22 Jan 2025 17:18:04 +0000 Received: from localhost ([127.0.0.1]:36217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1taeMd-0005rf-Qw for submit@debbugs.gnu.org; Wed, 22 Jan 2025 12:18:04 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:52571) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1taeMa-0005r3-4q for 75754@debbugs.gnu.org; Wed, 22 Jan 2025 12:18:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737566272; x=1737825472; bh=J/V30JTJOJsEJ9gOeN9dvn1G5O5IsxXiA06Ac5SJoAw=; 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=AgZXFywAEvcMMUE0K6IGWs92yyvDDXfqQaK/FBfhGAg6ScdvqrFmK9G0EfrQ4mMMd /K9EWFrT9z4zhxS5BoNVWeOz1ono8q2MZuclCIMrNajXbP7tArhAXOBtuNPKHCNGWv jKMiFvAJ7fWoaw0ZKjCnMjeLVpjtUr0mDQo92xzbRa7rwqXAnTbRRok/vf1sGUAUex s6BCTIy3i/RDfk4qNEtkUFo4MAns2VXSzGx6+HMP68I1I29TU7OnD3JZbC5bDRDv8D meYfZ1L6DrBPgw9SkKSs9ZltuJ/+KF9PzyoH6LR1TkdL9Ws3Bhgai04oR+v2vXgXoF CSlum3RQk29Ew== Date: Wed, 22 Jan 2025 17:17:47 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87frlabwem.fsf@protonmail.com> In-Reply-To: <86ikq63krq.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b3263a419070f4abca4a193a252ec6f4255c377e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: 75754@debbugs.gnu.org, eggert@cs.ucla.edu 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: Wed, 22 Jan 2025 10:18:32 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> While the alloca_size value is small, sa_avail is negative when we enter >> SAFE_ALLOCA, so SAFE_ALLOCA uses xmalloc to allocate the memory on the >> heap. >> >> The structure contains a Lisp_Object. This Lisp_Object must be >> protected from GC by being present on the C stack if GC can ever happen >> in this function. SAFE_ALLOCA doesn't protect it. >> >> I'm not entirely sure this is a problem, but >> >> (let ((print-unreadable-function (lambda (&rest args) (garbage-collect))= )) >> (format "%S" (symbol-function '+))) >> >> produces this backtrace: >> >> #0 garbage_collect () at alloc.c:6450 >> #1 0x00005555557f7700 in Fgarbage_collect () at alloc.c:6697 >> #2 0x000055555582e1ee in eval_sub (form=3DXIL(0x7ffff4dab073)) at eval.= c:2584 >> #3 0x0000555555828d9f in Fprogn (body=3DXIL(0)) at eval.c:439 >> #4 0x0000555555830604 in funcall_lambda (fun=3DXIL(0x555556045c9d), nar= gs=3D2, arg_vector=3D0x7fffffff6b78) at eval.c:3339 >> #5 0x000055555582f62d in funcall_general (fun=3DXIL(0x555556045c9d), nu= margs=3D2, args=3D0x7fffffff6b78) at eval.c:3033 >> #6 0x000055555582f89a in Ffuncall (nargs=3D3, args=3D0x7fffffff6b70) at= eval.c:3082 >> #7 0x0000555555863e8a in print_vectorlike_unreadable >> (obj=3DXIL(0x555555ee7765), printcharfun=3DXIL(0), escapeflag=3Dtrue= , buf=3D0x7fffffff6ce0 "\220m\377\377\377\177") at print.c:1683 >> #8 0x0000555555866e5f in print_object (obj=3DXIL(0x555555ee7765), print= charfun=3DXIL(0), escapeflag=3Dtrue) at print.c:2647 >> #9 0x0000555555862ec2 in print (obj=3DXIL(0x555555ee7765), printcharfun= =3DXIL(0), escapeflag=3Dtrue) at print.c:1296 >> #10 0x0000555555861cef in Fprin1_to_string (object=3DXIL(0x555555ee7765)= , noescape=3DXIL(0), overrides=3DXIL(0)) at print.c:814 >> #11 0x000055555581fd14 in styled_format (nargs=3D2, args=3D0x7fffffffca2= 0, message=3Dfalse) at editfns.c:3633 >> #12 0x000055555581f444 in Fformat (nargs=3D2, args=3D0x7fffffffca20) at = editfns.c:3370 >> >> indicating that GC can happen. >> >> The code attempts to protect the current argument by keeping it in a ^^^^^^^ This part is important: if there are several arguments, only one of them (at most) is protected by the automatic variable. >> redundant automatic variable: >> >> =09 Lisp_Object arg =3D spec->argument; >> ... >> =09 spec->argument =3D arg =3D Fprin1_to_string (arg, noescape, Qnil); > > I think indeed the protection here is by having the Lisp object in an > automatic variable. The important point is that protection appears to me to be insufficient, because there's a single automatic variable but many args. The very minor potential issue is that it is often an important optimization for code to know it is the sole owner of a malloc'd region. That's part of the reason ATTRIBUTE_MALLOC was added. The GCC analyzer certainly does very smart things with this attribute. The technical details of conservative GC are that an automatic variable has to live on the stack or in a register because it's the only way for the code to reproduce its value (if it's not reused, there's no harm in freeing it early). In this case, a very smart compiler might realize that it is the sole owner of the malloc'd memory (that's what ATTRIBUTE_MALLOC is about) and doesn't have to redundantly keep a stack variable representing a value it can read back from such memory. I wouldn't usually worry about this, because SAFE_ALLOC uses alloca or xmalloc and alloca isn't optimized. In this case, the alloca case is unreachable and presumably optimized out, so it's merely about modifying a variable which lives in two places in only one of them; with -Os, it'd be natural to modify the heap location directly and optimize out the register location. >> In any case, this protects only the current argument; if we detect a >> multibyte situation too late, we may restart the loop and, I think, >> reuse info->argument values which were unprotected during GC. > > Can you elaborate how this could happen by walking through the > relevant code? It's about this label: /* If we start out planning a unibyte result, then discover it has to be multibyte, we jump back to retry. */ retry: When we reach the label, we reestablish ispec (the current index into the info array), but not nspec (the last valid index into that array). That means that this code: =09 if ((conversion =3D=3D 'S' =09 || (conversion =3D=3D 's' =09=09 && ! STRINGP (arg) && ! SYMBOLP (arg)))) =09 { =09 if (EQ (arg, args[n])) =09=09{ =09=09 Lisp_Object noescape =3D conversion =3D=3D 'S' ? Qnil : Qt; =09=09 spec->argument =3D arg =3D Fprin1_to_string (arg, noescape, Qnil); =09=09 if (STRING_MULTIBYTE (arg) && ! multibyte) =09=09 { =09=09 multibyte =3D true; =09=09 goto retry; =09=09 } =09=09} =09 conversion =3D 's'; =09 } only has a real effect during the first attempt. I'll describe a scenario, but it might be best to test this and provide a gdb log: The first argument is converted to a unibyte string S. S is stored in info[0]->argument. This is one reference to it, the second one is "arg". We advance to the next argument, making "arg" refer to it and leaving S unprotected. Fine, as long as we don't call out to Lisp. But Vprint_unreadable_function is bound and we do call out to Lisp while trying to convert the second argument. GC happens and collects the first string. Then, the Lisp call returns and provides us with an unexpected multibyte string. So we set multibyte =3D true and goto retry, set "arg" to spec->argument, which is the now-invalid pointer to S. We then print it, but the string data of the collected string has been compacted and now points to another string's data. We call copy_text on SDATA (S), which copies bogus data into buf, which is then converted to a string and returned. However, as far as I can tell, with the old GC, print.c calls out to Lisp very rarely, so this is unlikely to happen in practice. With IGC, the situation is much worse: GC can strike at any time, fail to see the reference to the string in the xmalloc'd buffer, move the string or its data or both, and usually overwrites the old string right away (we could poison the old memory in this case, but doing so will destroy the old data which might have provided the only hint as to what was moved and where). My plan is to test this now, and if it does happen, unconditionally allocate a second SAFE_ALLOCA_LISP area, which will protect the arguments; my first attempt put a pointer to this area in the info struct, but I'm pretty sure that's unnecessary: we simply have to check the right index in both areas. If it doesn't happen with alloc.c, we should probably still do that; it's not obviously less efficient and the slight impact on readability will be outweighed by readers having to wonder about the redundantly-synched arg variable. Once the massive stack allocation has been fixed (in the simplest case, we simply accept that we exceed MAX_ALLOCA and remove the subtraction from sa_avail which accounts for the extra stack usage), performance should return to normal, and while we will have fixed the bug we can sleep soundly knowing that the fix only applies to rare cases anyway (in the simplest case, one would have to provide a 818-character format string to even run out of alloca space with the default settings). I'd like to reiterate my objection to the fact that SAFE_ALLOCA doesn't unconditionally scan all memory it has allocated for all GC implementations. That change in semantics would make both branches safer and we could take our time investigating potential bugs such as this one: until we decide the extra protection is no longer needed, bugs such as this one couldn't happen. Gerd did change SAFE_NALLOCA to scan its buffer on feature/igc, but not SAFE_ALLOCA. Gerd, can we simply: #define SAFE_ALLOCA(size) ({ void *buf; SAFE_NALLOCA(buf, size, 1); buf; }) for the time being? It might reduce the rush to fix this bug. >> On the feature/igc branch, where protection is definitely required, I'm >> thinking about a fix. A quick fix would be to replace all elements of >> struct info by Lisp_Object values and use SAFE_ALLOCA_LISP. > > Are automatic variables not protected on the igc branch as they are > with the old GC? Apart from the SDATA difference (in which case igc protects against GC but the old GC requires a no-GC assumption while the pointer is in use), the protection should be equivalent. When this failed to happen with -fomit-frame-pointer builds, we saw difficult bugs. The problem is that conservative stack marking isn't guaranteed to work by any C standard or ABI that I'm aware of. It used to be the case that an automatic variable would reside in one place so that was good enough; now, it's common for the only live reference to be an internal pointer. If we give the compiler extra space to play with, it might decide to use it, and that's what ATTRIBUTE_MALLOC does. > Can we use AUTO_STRING to solve the problem? No. It's strictly optional and cannot solve a problem that affects all builds. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 13:19:00 2025 Received: (at 75754) by debbugs.gnu.org; 22 Jan 2025 18:19:00 +0000 Received: from localhost ([127.0.0.1]:36374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tafJc-0000ld-CL for submit@debbugs.gnu.org; Wed, 22 Jan 2025 13:19:00 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:46917) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tafJZ-0000lI-QR for 75754@debbugs.gnu.org; Wed, 22 Jan 2025 13:18:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737569931; x=1737829131; bh=UueYyIj+FesukR0zXMxcPUn/fgHr3BVFqJM0bJq4L9Q=; 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=Ti5HM8Q78FNOmY8eDwxvA0V8/N8KCSS1lXYW3tI34GMLBQSmqQj/rplGiqQ+yHBL6 dFKMkxSDvbScrSLSu22+jRiVsCgxwGj38on+LZLMoBiwnEwgGSt7ZUjvNM5kt5jUiW mtp0LOVBdyffsNkWEttoCUAU8BBE2kCzCxZlYQ0wn1dYfqozIVRSybwU+amvUjLxEr W+OMpTgnXYqKuwh4nNZ369QvMtmJtZgyhdFEUDEJ9jl7br/OdvcSfDpHSEHWdQBPfA ClqS7eWXty7fx4uO8TFmvH9kOUQGimY3qVkUfwwBcltuUYEjFb6zwHHlrI3sEj7w7+ 1dGIQvitYtSNA== Date: Wed, 22 Jan 2025 18:18:48 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87msfiaf0h.fsf@protonmail.com> In-Reply-To: <86ikq63krq.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 142e405815424b694637d8a8d9aca51b15189982 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: 75754@debbugs.gnu.org, eggert@cs.ucla.edu 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 (-) (setq print-unreadable-function (lambda (&rest args) (garbage-collect) (make-string 100 256 t))) (message "%S" (format "%S %S" [1] (symbol-function '+))) fails to print the initial "[1]" here. Changing 256 to ?A and t to nil produces "[1] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" GDB session confirms the bug is as I've described. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 22 14:39:53 2025 Received: (at 75754) by debbugs.gnu.org; 22 Jan 2025 19:39:53 +0000 Received: from localhost ([127.0.0.1]:36632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tagZt-0004r5-9b for submit@debbugs.gnu.org; Wed, 22 Jan 2025 14:39:53 -0500 Received: from mail-10630.protonmail.ch ([79.135.106.30]:35943) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tagZq-0004qm-Gg for 75754@debbugs.gnu.org; Wed, 22 Jan 2025 14:39:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737574782; x=1737833982; bh=abhvPKJ6I4UnoWpCX++vIWi4X7vqF57+eU6oMfa9a30=; 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=yitYG00ZZKT+xRG1WHhH0jLFetvOUMrAdmMNdNkuh5xe2Y8YKfdHySU0bfiHrSiIX vYCF/8IxPiO7KIeNQxJWLg2QdpuTYGrw4q+9iqpqxdZxrMv5GBJqy2ayp0/irWjYQO GR5CI8hZvHB3HcxmzwkATKZbOpMFidMhEjSXYTzUimltcc+ZvgTYQl7Cwn0Q1yTA18 8XtpACvxjKYArD5Zq5A6mwOln+F9ZlKK2v2l9SY1ZeYjCAKlnEBl1bfhErUN3ZCBJS F/E/BxSEyYm8UQVncLWLCetJZyFQjeMWcTzgjZV7HOe88MRP4NWcfkvTtsvpYNOWa6 RTL7t24QWIDEQ== Date: Wed, 22 Jan 2025 19:39:35 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <878qr2ab9v.fsf@protonmail.com> In-Reply-To: <86ikq63krq.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7fb64552def9b11f0d16af197d2639c4cd81abdd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: 75754@debbugs.gnu.org, eggert@cs.ucla.edu 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 writes: > (setq print-unreadable-function > (lambda (&rest args) > (garbage-collect) > (make-string 100 256 t))) > > (message "%S" (format "%S %S" [1] (symbol-function '+))) > > fails to print the initial "[1]" here. Changing 256 to ?A and t to nil > produces > > "[1] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > > GDB session confirms the bug is as I've described. Patch: >From caa546d3df5e6a23d36d6d60834da655bf407ba4 Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH] Fix GC bug causing incorrect 'format' output (Bug#75754) This fixes the correctness bug discovered in bug#75754, but not the performance issue or excessive stack usage. * src/editfns.c (styled_format): Allocate Lisp_Object array using SAFE_ALLOCA_LISP, not SAFE_ALLOCA. --- src/editfns.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/src/editfns.c b/src/editfns.c index 8a5fb673fe7..fa138061105 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -3431,10 +3431,6 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, b= ool message) /* Information recorded for each format spec. */ struct info { - /* The corresponding argument, converted to string if conversion - was needed. */ - Lisp_Object argument; - /* The start and end bytepos in the output string. */ ptrdiff_t start, end; =20 @@ -3461,6 +3457,10 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, b= ool message) || SIZE_MAX < alloca_size) memory_full (SIZE_MAX); info =3D SAFE_ALLOCA (alloca_size); + /* Ose argument belonging to each spec, but needs to be allocated + separately so GC doesn't free the strings (bug#75754). */ + Lisp_Object *spec_arguments; + SAFE_ALLOCA_LISP (spec_arguments, nspec_bound); /* discarded[I] is 1 if byte I of the format string was not copied into the output. It is 2 if byte I was not the first byte of its character. */ @@ -3610,14 +3610,15 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, = bool message) =09 if (! (n < nargs)) =09 error ("Not enough arguments for format string"); =20 -=09 struct info *spec =3D &info[ispec++]; +=09 ptrdiff_t spec_index =3D ispec++; +=09 struct info *spec =3D &info[spec_index]; =09 if (nspec < ispec) =09 { -=09 spec->argument =3D args[n]; +=09 spec_arguments[spec_index] =3D args[n]; =09 spec->intervals =3D false; =09 nspec =3D ispec; =09 } -=09 Lisp_Object arg =3D spec->argument; +=09 Lisp_Object arg =3D spec_arguments[spec_index]; =20 =09 /* For 'S', prin1 the argument, and then treat like 's'. =09 For 's', princ any argument that is not a string or @@ -3630,7 +3631,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bo= ol message) =09 if (EQ (arg, args[n])) =09=09{ =09=09 Lisp_Object noescape =3D conversion =3D=3D 'S' ? Qnil : Qt; -=09=09 spec->argument =3D arg =3D Fprin1_to_string (arg, noescape, Qnil); +=09=09 spec_arguments[spec_index] =3D arg =3D Fprin1_to_string (arg, noes= cape, Qnil); =09=09 if (STRING_MULTIBYTE (arg) && ! multibyte) =09=09 { =09=09 multibyte =3D true; @@ -3648,7 +3649,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bo= ol message) =09=09 multibyte =3D true; =09=09 goto retry; =09=09 } -=09=09 spec->argument =3D arg =3D Fchar_to_string (arg); +=09=09 spec_arguments[spec_index] =3D arg =3D Fchar_to_string (arg); =09=09} =20 =09 if (!EQ (arg, args[n])) @@ -3658,7 +3659,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bo= ol message) =20 =09 if (SYMBOLP (arg)) =09 { -=09 spec->argument =3D arg =3D SYMBOL_NAME (arg); +=09 spec_arguments[spec_index] =3D arg =3D SYMBOL_NAME (arg); =09 if (STRING_MULTIBYTE (arg) && ! multibyte) =09=09{ =09=09 multibyte =3D true; @@ -4303,9 +4304,9 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bo= ol message) =09for (ptrdiff_t i =3D 0; i < nspec; i++) =09 if (info[i].intervals) =09 { -=09 len =3D make_fixnum (SCHARS (info[i].argument)); +=09 len =3D make_fixnum (SCHARS (spec_arguments[i])); =09 Lisp_Object new_len =3D make_fixnum (info[i].end - info[i].start)= ; -=09 props =3D text_property_list (info[i].argument, +=09 props =3D text_property_list (spec_arguments[i], make_fixnum (0), len, Qnil); =09 props =3D extend_property_ranges (props, len, new_len); =09 /* If successive arguments have properties, be sure that --=20 2.47.1 From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 00:47:55 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 05:47:55 +0000 Received: from localhost ([127.0.0.1]:38667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1taq4J-0005RD-6C for submit@debbugs.gnu.org; Thu, 23 Jan 2025 00:47:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46622) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1taq4G-0005Qy-Cq for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 00:47:54 -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 1taq49-0003gR-C2; Thu, 23 Jan 2025 00:47:45 -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=qthHmqeMLHja7V8fOFRXFjIUx3/uSLGAKHZIYmoxWTo=; b=kCXrhGI1QZqB 5CSFrcWEph1SbTw2cuP1J7W8ZRct30g606wFY4liX92iU8SvO6zyheoh4WXOqIWycHv8PvdLup30i 0NgotyOHOjcfhl9rnroNDQqeexVrQTL3rvGejpbtEzHT6pmunuDnyYbhd1KiCsYEnzcOj9bHkJOpq URikf4cq/kEY1DvjzonzyuL00RP2Hz7jqL3PjSTHmZ60Wi5iEll/XKjo+4Q0OcqzPnNKzao1hrwja 4OoSaAaEiJ/JuDV8jEEvOUdCC3NgAoJzOBah7igyil3rkZtj0mFvolC0dRArgOyf3cz3QAUAKbyPS JKEEXgdQWuYa0Qs2ImrqWA==; Date: Thu, 23 Jan 2025 07:47:42 +0200 Message-Id: <86bjvy2i9t.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet , eggert@cs.ucla.edu In-Reply-To: <878qr2ab9v.fsf@protonmail.com> (message from Pip Cet on Wed, 22 Jan 2025 19:39:35 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: 75754@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 (---) > Date: Wed, 22 Jan 2025 19:39:35 +0000 > From: Pip Cet > Cc: 75754@debbugs.gnu.org, eggert@cs.ucla.edu > > Pip Cet writes: > > > (setq print-unreadable-function > > (lambda (&rest args) > > (garbage-collect) > > (make-string 100 256 t))) > > > > (message "%S" (format "%S %S" [1] (symbol-function '+))) > > > > fails to print the initial "[1]" here. Changing 256 to ?A and t to nil > > produces > > > > "[1] AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > > > > GDB session confirms the bug is as I've described. > > Patch: Thanks. Paul, any comments on the issue and/or the patch? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 12:24:22 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 17:24:22 +0000 Received: from localhost ([127.0.0.1]:42147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tb0wI-0002GS-EX for submit@debbugs.gnu.org; Thu, 23 Jan 2025 12:24:22 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:54500) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb0wE-0002GC-PS for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 12:24:20 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0C4AC3C082C8B; Thu, 23 Jan 2025 09:24:13 -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 ew7yEj9T-VZy; Thu, 23 Jan 2025 09:24:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C55ED3C082C8E; Thu, 23 Jan 2025 09:24:12 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu C55ED3C082C8E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1737653052; bh=+n6i22hB6RbpjvLRgruLw5pSHtbIDQ7u+tJfXB83AEA=; h=Message-ID:Date:MIME-Version:To:From; b=Dlc32OmqU+LcpcOaon4gOlkHcB1WgqUpy0Z/41CgF30EkRzTDsBpxRvdCDrWA1Jcj UAdO1chF79W0RIXwyi6ZHjX4ZajHZaZIVd0NEbeJ3YGuColOcmhKm4iA7sMoN+J6ZB s5q/8HXIgxBobPj1hywjMOLkeX770fwyYsFbapPakgalH73QebYykSXjzPs4Vts47t dj7XaVLtvP8k4t0Dg+wvTEsaMjh5GeFqxj7pB2nkThSsTilUWg8rWR4xX3HEuWuVss pyGGzD/cpqSZ9Rh/5nivcOcvjPdzbX+79JbiPJVVkXRIBhej4krbd5IcdV6vQcXh3g gK/tx241UGIHQ== 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 M0i7NjOJWzEb; Thu, 23 Jan 2025 09:24:12 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id AB32F3C082C8B; Thu, 23 Jan 2025 09:24:12 -0800 (PST) Message-ID: <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> Date: Thu, 23 Jan 2025 09:24:12 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#75754: styled_format stack usage/GC protection To: Eli Zaretskii , Pip Cet References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86bjvy2i9t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: 75754@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: -1.0 (-) On 2025-01-22 21:47, Eli Zaretskii wrote: > Paul, any comments on the issue and/or the patch? Patch looks OK except for the "Ose" in a comment. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 12:50:03 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 17:50:03 +0000 Received: from localhost ([127.0.0.1]:42218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tb1L8-0003UI-Up for submit@debbugs.gnu.org; Thu, 23 Jan 2025 12:50:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36346) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb1L7-0003Te-1I for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 12:50: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 1tb1L0-0002xH-BG; Thu, 23 Jan 2025 12:49: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=8eLaR2XU60NWUcQQBbwlJb8FH0MBqGOduxVqNelO0bo=; b=VNofEtqY3VKI xJMNMAgulLj9Sn4mbQxOVn6c1teRpE6jlA3O1guI6YmOWrc7RYcTueNloLx0DqiNDzTtKAhR2QpQL xL430ZyE0122vXuluwP2GLPz0kO4np3oYBXJ4gYAyMcQ2s6rGExzOgK/+/LI1C34Zvvs+p8UZgoj4 mllUsqFJ5qFkzspYjP1imV6wS2nDmYxEn/L8OmgEGGmTA+PmnIJSzkeQDBAAZwW+1uAlb+/klvyH5 M2ceQSXcYhyMll9nPJsOOqtz7g8DiaA9unx9d+A7nQ1CVpF3cXc17uXAY0NHt4GGQr7K3OlT3/ZWf ibyeJpLwThddeRJYjgSRfA==; Date: Thu, 23 Jan 2025 19:49:35 +0200 Message-Id: <86o6zxzahc.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-Reply-To: <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> (message from Paul Eggert on Thu, 23 Jan 2025 09:24:12 -0800) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: pipcet@protonmail.com, 75754@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 (---) > Date: Thu, 23 Jan 2025 09:24:12 -0800 > Cc: 75754@debbugs.gnu.org > From: Paul Eggert > > On 2025-01-22 21:47, Eli Zaretskii wrote: > > Paul, any comments on the issue and/or the patch? > > Patch looks OK except for the "Ose" in a comment. Thanks. I think it would be good to have a test for this, if that is feasible. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 14:32:59 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 19:32:59 +0000 Received: from localhost ([127.0.0.1]:42430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tb2wk-00008A-Om for submit@debbugs.gnu.org; Thu, 23 Jan 2025 14:32:59 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:21575) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb2wh-00007s-Fd for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 14:32:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737660768; x=1737919968; bh=7in3n+NDm1c67aAuswNZfEljCvb2/0YMWZvr9iw2YRs=; 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=iZoJ6xZOjmYyesDTCC7U9f8KYXwiqPCNwXW9Mq8x+yceg/vVJNbaLs9tTDXmQTq+D Uw5QpPTsfVfHUBigmeWd3d8n6orQdlxIYq3/dyFVeJbnSjnxI/K5xiavGWzO9zb5kT YMfiJa2RNtcP9/prw7a0hJSqMhcwzeRuq7gWPhIU3rJPiwRJVdGLzGo5wkDpqC9bO2 CTgSq3bjoRbAwkHF2ujBzeAqfgRuHHMwh8jXPOzOruoAGcMs3IPqvq84bom0CHbZdb FbiqYucSrOXkfkVxBFg2Rm11LlJcwzOTr1YYm4WKUEFUSIEleGgO4EO5f32CagkgFD fIcxN2QtnDtxA== Date: Thu, 23 Jan 2025 19:32:44 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87jzal2uni.fsf@protonmail.com> In-Reply-To: <86o6zxzahc.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 6b300d25f298eb8466480afe599e37fcb29d1f16 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: Paul Eggert , 75754@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: -1.0 (-) "Eli Zaretskii" writes: >> Date: Thu, 23 Jan 2025 09:24:12 -0800 >> Cc: 75754@debbugs.gnu.org >> From: Paul Eggert >> >> On 2025-01-22 21:47, Eli Zaretskii wrote: >> > Paul, any comments on the issue and/or the patch? >> >> Patch looks OK except for the "Ose" in a comment. > > Thanks. > > I think it would be good to have a test for this, if that is feasible. While I don't think a test would be a bad thing per se (feel free to use the code I posted, of course), I don't think it's the most sensible use of resources here: the precise situation is unlikely to occur again unless the patch is reverted, and similar bugs wouldn't be caught by this test. The most worrying aspect of this wasn't that there was a GC bug and we used a free'd string, it was that we didn't crash at that point, but silently treated the string as empty, but that's for bug#75768. And while I do think we should revisit the safety of SAFE_ALLOCA (scanning the extra memory as though it were on the stack seems easy, but I haven't tried) and SDATA (pinning the sblocks in memory is doable, I've got a patch, but there are subtle performance issue), those also could benefit from broader discussion. At the very least, a separate bug report. (In both of these cases, the feature/igc branch currently chooses the safer approach; in the case of SDATA, it must. In the case of SAFE_ALLOCA, we could introduce an unsafe version for some situations in which we are absolutely convinced no Lisp data can ever live in the xmalloc'd block, but so far it's not been required for performance. Many places use SDATA in situations where they expect no GC can happen, and there are no comments or macros indicating this to us, so deciding whether this is one of the cases is impossible. I mention this because this is likely to be the last such bug we find because it was buggy on both branches but caused problems only on feature/igc.) So, assuming no one volunteers to write a specific test, let's close this bug. Pip From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 15:33:03 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 20:33:03 +0000 Received: from localhost ([127.0.0.1]:42554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tb3ss-000395-5n for submit@debbugs.gnu.org; Thu, 23 Jan 2025 15:33:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb3sn-00038f-LY for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 15:33:00 -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 1tb3sg-0005mC-4X; Thu, 23 Jan 2025 15:32:50 -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=PLXf2vSWuSBfSOs+UznXcsj2WTxvyS5WO/PIxVFbcug=; b=C6nn/4Xb2U+iAj8IhPFc fAopZbbD275JOGhu9zDLWB5qEXn1v+vTZxqWAX+RurXfg5oTKW37PNMPox5sJehBEfFn+jmKdlu5z lLSGzeO5arZyc8zYG+MSs8jWyZtVA7qKEEfoQGNiJPMxfy1wbcxKJUzs48JzNL/ifnph/dLhp4xNb EnXd39IOF7qq4vhgPMFMU8+tMB46RdbUc9YFdEnXrtHiJqywYi6aCVm1Ahwn2cGOwwk30JODVIFkg mmFX6WTq+ihEOFlt/y0GpikEKIwZgnetOTodLHmfN/5ZoYRgUKWuIfDaBhviw+28O/MXtjlJLblYI E47SfXzZg+juzw==; Date: Thu, 23 Jan 2025 22:32:31 +0200 Message-Id: <864j1pz2xs.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87jzal2uni.fsf@protonmail.com> (message from Pip Cet on Thu, 23 Jan 2025 19:32:44 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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 (---) > Date: Thu, 23 Jan 2025 19:32:44 +0000 > From: Pip Cet > Cc: Paul Eggert , 75754@debbugs.gnu.org > > So, assuming no one volunteers to write a specific test, let's close > this bug. I wrote a test: diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el index 9fff425..6da3c73 100644 --- a/test/src/editfns-tests.el +++ b/test/src/editfns-tests.el @@ -534,4 +534,14 @@ editfns-tests--before/after-change-functions 'utf-8 nil (current-buffer)) (should (null (sanity-check-change-functions-errors)))))) +(ert-deftest editfns-tests-styled-print () + (let* ((print-unreadable-function + (lambda (&rest args) + (garbage-collect) + (make-string 100 ?Ā t))) + (str "\"[1] ĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀ\"")) + (should (string= + (format "%S" (format "%S %S" [1] (symbol-function '+))) str)))) + + ;;; editfns-tests.el ends here It fails (after rebuilding with commit ed5067e689a5): Test editfns-tests-styled-print backtrace: signal(ert-test-failed (((should (string= (format "%S" (format "%S % ert-fail(((should (string= (format "%S" (format "%S %S" [1] (symbol- (if (unwind-protect (setq value-602 (apply fn-600 args-601)) (setq f (let (form-description-604) (if (unwind-protect (setq value-602 (app (let ((value-602 'ert-form-evaluation-aborted-603)) (let (form-descr (let* ((fn-600 #'string=) (args-601 (condition-case err (list (forma (let* ((print-unreadable-function #'(lambda (&rest args) (garbage-co #f(lambda () [t] (let* ((print-unreadable-function #'...) (str "\"[1 #f(compiled-function () #)() handler-bind-1(#f(compiled-function () #) id 1tb5pk-0000WO-2C for submit@debbugs.gnu.org; Thu, 23 Jan 2025 17:37:56 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:29253) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb5ph-0000W8-Fa for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 17:37:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737671867; x=1737931067; bh=L/Y9uIwsGqapzp1BfHTzDy5y9PeMtghq7bHCnUlTaa4=; 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=yjtIlkxidSnCI7SELD1IDgop4/dss247QBw08+iNY+4nFt3LqkGKLWfqq5gaR9kqm QwCq+MbsFKKs8OsW4d9c9UsQfPreCr6nnqbYcgAnGa7AmrO/rrpgQSMtANnPyOOBsM gWNNW90PaJlwJCFp3gJgIrgYabhIJLZYDgQ4xWWPNJ1wO31KM1dZoV83AeYIKwQAfT l3b/bDN9gH1zAFL/kZ2yrrTxRDqp2TmJB0npna7xZqPqxmeddpfrZQswr56cUiAJxG IwzjTpcdr1rcYLjSOEhfOgPcKV+Qlt9NnaXZPQ0mocNLtqEb3aWF6e9I36H02VEojw Kx2gyAsrJ1GpA== Date: Thu, 23 Jan 2025 22:37:43 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87msfh17is.fsf@protonmail.com> In-Reply-To: <864j1pz2xs.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0e03c3d71abb059fb73e69a6c742fb34c553e7d3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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: -1.0 (-) "Eli Zaretskii" writes: > What did I miss? Can we make this a new bug? This one is SDATA, not SAFE_ALLOCA. diff --git a/src/editfns.c b/src/editfns.c index 4ba356d627c..23a5f9aeac6 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -3491,7 +3491,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bo= ol message) /* If we start out planning a unibyte result, then discover it has to be multibyte, we jump back to retry. */ retry: - + format_start =3D SSDATA (args[0]); p =3D buf; nchars =3D 0; =20 should fix it. Pip From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 23 18:58:58 2025 Received: (at 75754) by debbugs.gnu.org; 23 Jan 2025 23:58:58 +0000 Received: from localhost ([127.0.0.1]:42843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tb76A-0004BE-6P for submit@debbugs.gnu.org; Thu, 23 Jan 2025 18:58:58 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:45877) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tb767-0004B0-Ow for 75754@debbugs.gnu.org; Thu, 23 Jan 2025 18:58:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737676727; x=1737935927; bh=FbYhoXF5gfNkJpjCUjZUjqkWM9jr96TbwB+gzZHGoRE=; 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=Jut6enrPD5NZH7vkjzmF7lGWD+yH3sni1E92+Xkv7PcjxJ15xpWXEM1ci3+oUVgNT yQdzViRBxI/oBpPjieJyZHrU6pYm5fdGV929QxGlJqUPtzx9lrJk85lylqXl4U9Z4g xFUybqXk+OshMU2BjvPEFghS6IkHlX1eY79ttKsIER1RZtuRrFrYkHnDB/vR8Onzmv eWV9msJsARUgypaJCHe/NAf7ZTclLJeYXxmX0AC4IEUBh+LT6EBZF6PGc1EawZCByZ r+elFZNrVOTshPo4x7ltOJnEyigXlW+v7GZqc3hiSINXQhI2g7jPLDzLp3SxWW+dl/ YZR0ZFtWFLQzQ== Date: Thu, 23 Jan 2025 23:58:41 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87ed0t13ru.fsf@protonmail.com> In-Reply-To: <864j1pz2xs.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: d322ad8356408a385728d3b5281e1d277e974b5b MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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: -1.0 (-) Pip Cet writes: > "Eli Zaretskii" writes: > >> What did I miss? > > Can we make this a new bug? Whether this is the same bug or a different one depends on how you look at it: both can be interpreted as a violated no-GC assumption, or the first one can be interpreted as a result of the excessive stack usage while the second one is due to SDATA relocation. There are three ways to fix the SDATA relocation issue: 1. Reload format_start and format (and end, and format0) after every call w= hich might have GC'd. If you think we should do this, please tell me whether lisp_string_width can GC. More importantly, assuming it doesn't, document this in every function in the call tree starting at lisp_string_width so we don't accidentally change it. 2. memcpy the format string. Two-liner, more likely to fix the bug for good than (1), wastes more memory (since sa_avail has been negative since we entered the function, this is xmalloc'd memory). 3. replace format by a ptrdiff_t and all instances of *format by SREF (args[0], index). Faster than 2, but many changes hurting readability. > diff --git a/src/editfns.c b/src/editfns.c > index 4ba356d627c..23a5f9aeac6 100644 > --- a/src/editfns.c > +++ b/src/editfns.c > @@ -3491,7 +3491,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, = bool message) > /* If we start out planning a unibyte result, > then discover it has to be multibyte, we jump back to retry. */ > retry: > - > + format_start =3D SSDATA (args[0]); > p =3D buf; > nchars =3D 0; > =20 > > should fix it. Just be clear here: that fixes the specific test. It does not fix the bug. Here's (2), which seems most doable and, I think, may fix the bug, unless there's a subtlety I missed. diff --git a/src/editfns.c b/src/editfns.c index 4ba356d627c..72cbbb51c40 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -3442,9 +3442,10 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, b= ool message) } *info; =20 CHECK_STRING (args[0]); - char *format_start =3D SSDATA (args[0]); bool multibyte_format =3D STRING_MULTIBYTE (args[0]); ptrdiff_t formatlen =3D SBYTES (args[0]); + char *format_start =3D SAFE_ALLOCA (formatlen); + memcpy (format_start, SSDATA (args[0]), formatlen); bool fmt_props =3D !!string_intervals (args[0]); =20 /* Upper bound on number of format specs. Each uses at least 2 chars. = */ Note that (3) technically introduces another bug: we call out to Lisp, which can modify args[0], causing it to be resized if it's multibyte. We'd use the old bytecount, and might read past the end of the string. feature/igc avoids all of these problems by keeping SDATA pointers valid, even when the string is resized. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 02:42:06 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 07:42:06 +0000 Received: from localhost ([127.0.0.1]:43450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbEKL-0000Ee-RQ for submit@debbugs.gnu.org; Fri, 24 Jan 2025 02:42:06 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46578) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbEKG-0000Dv-4z for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 02:42:03 -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 1tbEKA-0005D4-38; Fri, 24 Jan 2025 02:41: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=RSL1VktDOCCR2L195Y0K2PXr7pYs21MJYWojLbmf+As=; b=WgAENXyEdItu ueRTZIpeJcbyJOYaWQsuaPQDAPJYJs5x2B2yH1hcuKhAGdikw+LUpycQKy4qc7kW9XmoT7jx33kWq v+7Z0B8Y/xNEz5M2yW7cMkMVRwpP45NWfawbgzCpPbmfpg9YeQ75i+rM5/2GvU34P2IvwuKniOK8W 8PxCSCSGBUYJwy4SGh2Ad2obghBTAoLiMDXS0TV9X+VdWGN3XXvvoZRZIgtJpBYbRNrw6A64wwXSE k/VEOlPb7qZYuiQTDNNsdv87p9esvBiM3BmXW+zE7qAemLfwWRgD1KrprWgyMYSziLangua8Xm47a exjY9l9kRCUhbPuM5u7lhQ==; Date: Fri, 24 Jan 2025 09:41:47 +0200 Message-Id: <86tt9oy7yc.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87msfh17is.fsf@protonmail.com> (message from Pip Cet on Thu, 23 Jan 2025 22:37:43 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87msfh17is.fsf@protonmail.com> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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 (---) > Date: Thu, 23 Jan 2025 22:37:43 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > What did I miss? > > Can we make this a new bug? We could, or we could keep discussing that in this bug (since this is still about styled_format). > This one is SDATA, not SAFE_ALLOCA. > > diff --git a/src/editfns.c b/src/editfns.c > index 4ba356d627c..23a5f9aeac6 100644 > --- a/src/editfns.c > +++ b/src/editfns.c > @@ -3491,7 +3491,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool message) > /* If we start out planning a unibyte result, > then discover it has to be multibyte, we jump back to retry. */ > retry: > - > + format_start = SSDATA (args[0]); > p = buf; > nchars = 0; > > > should fix it. Didn't try it yet, since we are still discussing what to do. But I would like to install the test, for now as expected to fail. WDYT? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 03:16:43 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 08:16:43 +0000 Received: from localhost ([127.0.0.1]:43530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbErr-0001sT-A9 for submit@debbugs.gnu.org; Fri, 24 Jan 2025 03:16:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37326) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbErn-0001sB-5k for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 03:16:41 -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 1tbErh-0000oP-3X; Fri, 24 Jan 2025 03:16:33 -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=u4ykSNQuTk1b7RoQmt945n7CWyiXLy+EWHbKahW7ctw=; b=UGxmfAiQwbt7 bIpPHR0UKOdlC6ZbaaVWHb3Fbdz2zj6YFY83yJNAX7kcd7J4AtIDx5WyDH7s+KntPiY9LsAUPZGrf gfjgzYWquA8Fil/Mc/lIlQ05INGZ1AOcMpnJxj7ffWBk6tLRYqXDZRwL8hJR12t467NFlQ9Cqdzno uIV8LNIz4MNGFW7FlLB7737gviAzuYEOnq26GfFAHIPtIwgXGvx7jCvVbXzRpyy4uHyCu5raI/VYy jOAgaJ1ToizkOrUjdJxZy4dSFCZLRmi3H5dybNj9mT70fAeLxalpxnORYwXjjsuFdGP8wRZFhohxO 0Kp/nKntPQ8x3Bs6nVtu7g==; Date: Fri, 24 Jan 2025 10:16:28 +0200 Message-Id: <86plkcy6cj.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87ed0t13ru.fsf@protonmail.com> (message from Pip Cet on Thu, 23 Jan 2025 23:58:41 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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 (---) > Date: Thu, 23 Jan 2025 23:58:41 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org > > 1. Reload format_start and format (and end, and format0) after every > call which might have GC'd. If you think we should do this, please > tell me whether lisp_string_width can GC. It can, if called with the last argument 'true' (because find_automatic_composition calls into Lisp). Currently, we call it with 'false', so it cannot. > More importantly, assuming it doesn't, document this in every > function in the call tree starting at lisp_string_width so we don't > accidentally change it. > > 2. memcpy the format string. Two-liner, more likely to fix the bug for > good than (1), wastes more memory (since sa_avail has been negative > since we entered the function, this is xmalloc'd memory). > > 3. replace format by a ptrdiff_t and all instances of *format by > SREF (args[0], index). Faster than 2, but many changes hurting > readability. I prefer (2), I think. Assuming it indeed fixes the problem. > > + format_start = SSDATA (args[0]); > > p = buf; > > nchars = 0; > > > > > > should fix it. > > Just be clear here: that fixes the specific test. It does not fix the > bug. Can we have a test for "the rest" of the bug, which is not fixed by the above? > Here's (2), which seems most doable and, I think, may fix the bug, > unless there's a subtlety I missed. > > diff --git a/src/editfns.c b/src/editfns.c > index 4ba356d627c..72cbbb51c40 100644 > --- a/src/editfns.c > +++ b/src/editfns.c > @@ -3442,9 +3442,10 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args, bool message) > } *info; > > CHECK_STRING (args[0]); > - char *format_start = SSDATA (args[0]); > bool multibyte_format = STRING_MULTIBYTE (args[0]); > ptrdiff_t formatlen = SBYTES (args[0]); > + char *format_start = SAFE_ALLOCA (formatlen); > + memcpy (format_start, SSDATA (args[0]), formatlen); > bool fmt_props = !!string_intervals (args[0]); Does this assume anything about formatlen, like that it doesn't exceed the alloca limit? If so, should we have an assertion about that? > feature/igc avoids all of these problems by keeping SDATA pointers > valid, even when the string is resized. Unless the string is GC'ed, right? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 07:51:39 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 12:51:39 +0000 Received: from localhost ([127.0.0.1]:44079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbJ9u-0006Zd-J2 for submit@debbugs.gnu.org; Fri, 24 Jan 2025 07:51:39 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:41771) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbJ9r-0006ZI-FX for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 07:51:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737723088; x=1737982288; bh=3GmBlJZJsnp8PX9v+uebIpKhg8lmZiwgP2K6nOrrrqA=; 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=wZ2VfA67MrYU1U/UdaFtPFEKmNE5UmE7U2gR4wwEcQIBBHwFbWy5gkb3y7tUwUFzx ZbqlGtZe+GBfLpCKfhbisJWs7uJ53+Jy4YY0w77ZKxF2+SoPwZTwz3kGazkdIwxRAm 0NbwSAa91dLbCLgjvLDIao17SaLBlIHaobdcaqrCh4on1bxPxL/i1Poezy0PgEEdJ0 lv9hE5Gw9mtOFOLEy1pbnWdyksWWIIR0fan8sSoe9NmnfaDJeenuroxH10W+5HfMCR wl+/+Hj60TZlA15FWgb9MQznvLhIgcrb/UN9/rkJ0YZCGuel5Cx5fF0cYCxqjg+0A5 ANhIQtgBQx/4g== Date: Fri, 24 Jan 2025 12:51:22 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <874j1o1ikj.fsf@protonmail.com> In-Reply-To: <86plkcy6cj.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 33cd73485061b8597472c782868f54dc7def5032 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, Michael Albinus , 75754@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: -1.0 (-) Michael Albinus, could you please C-s ert-how in this message and comment briefly if appropriate? I think adding a new defstruct may help improve ert in at least three ways, including this one. Please indicate whether this would be *potentially* acceptable; if it is, I'll prepare a separate bug. If it isn't, I might have to think of something else. "Eli Zaretskii" writes: >> Date: Thu, 23 Jan 2025 23:58:41 +0000 >> From: Pip Cet >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org >> >> 1. Reload format_start and format (and end, and format0) after every >> call which might have GC'd. If you think we should do this, please >> tell me whether lisp_string_width can GC. > > It can, if called with the last argument 'true' (because > find_automatic_composition calls into Lisp). Currently, we call it > with 'false', so it cannot. Is this documented anywhere? >> More importantly, assuming it doesn't, document this in every >> function in the call tree starting at lisp_string_width so we don't >> accidentally change it. >> >> 2. memcpy the format string. Two-liner, more likely to fix the bug for >> good than (1), wastes more memory (since sa_avail has been negative >> since we entered the function, this is xmalloc'd memory). >> >> 3. replace format by a ptrdiff_t and all instances of *format by >> SREF (args[0], index). Faster than 2, but many changes hurting >> readability. > > I prefer (2), I think. Assuming it indeed fixes the problem. I'll let you know when I'm (reasonably) certain. > >> > + format_start =3D SSDATA (args[0]); >> > p =3D buf; >> > nchars =3D 0; >> > >> > >> > should fix it. >> >> Just be clear here: that fixes the specific test. It does not fix the >> bug. > > Can we have a test for "the rest" of the bug, which is not fixed by > the above? Thank you very much for suggesting this: if I hadn't been wrong about the first test case being useful (it was), I'd probably have refused. While writing this test didn't uncover new bugs, it was an educational experience. New test: (ert-deftest editfns-tests-styled-print () (let* ((gc-me (copy-sequence "foo")) (print-unreadable-function =09 (lambda (&rest args) (make-string 10 10 t) (garbage-collect) (make-string 10 10 t) (prog1 (make-string 100 ?=C4=80 t) (setq gc-me nil) (make-string 10 10 t)))) (str "\"[1] =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80 =C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80 =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80\"")) (should (string=3D (format "%S" (format (copy-sequence "%S %S %S %S") [1] (symbol-function '+) (symbol-function '*) (symbol-function '-))) str)))) The "problem" writing this test is that string compaction is very often idempotent: the only way a string is moved again in a second GC is when another string which is *older* than the string moved in the first GC is freed. That's 'gc-me', which must be live during the first call to garbage-collect but unreachable for the second call. While I figured out how to do this for this specific test, it'd be nicer to just run make check-gc and stress-test the garbage collector in ways known to have caused problems. (Brief proposal relevant to several issues: If we want to test GC bugs more thoroughly, we need a way to tell ert to run them in a special way. I proposed extending ert with an ert-how defstruct for the make benchmark target, indicating "how" a test is to be run, and implemented it, but I don't think I've sent the patch yet. Using this structure to create conditions for testing for GC bugs would be possible, and it would also be an easier way to make crash tests print a message before they're run. Of course, this would in no way imply a decision to use this structure, or ERT, for "make benchmark". Using it for GC testing or indicating crash tests would be sufficient reason to add it, IMHO. While this needs more thought, if it's obviously unacceptable for a simple reason I haven't thought of, please let me know so I won't waste time on it. Of course the final decision will have to be made based on an actual patch, but if we can have a quick "no" right now I'd appreciate it.) >> Here's (2), which seems most doable and, I think, may fix the bug, >> unless there's a subtlety I missed. >> >> diff --git a/src/editfns.c b/src/editfns.c >> index 4ba356d627c..72cbbb51c40 100644 >> --- a/src/editfns.c >> +++ b/src/editfns.c >> @@ -3442,9 +3442,10 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args= , bool message) >> } *info; >> >> CHECK_STRING (args[0]); >> - char *format_start =3D SSDATA (args[0]); >> bool multibyte_format =3D STRING_MULTIBYTE (args[0]); >> ptrdiff_t formatlen =3D SBYTES (args[0]); >> + char *format_start =3D SAFE_ALLOCA (formatlen); >> + memcpy (format_start, SSDATA (args[0]), formatlen); >> bool fmt_props =3D !!string_intervals (args[0]); > > Does this assume anything about formatlen, like that it doesn't exceed > the alloca limit? If so, should we have an assertion about that? No. We're already past the alloca limit at his point so SAFE_ALLOCA will always call xmalloc here (that's the "excessive stack usage" part of this bug, which remains unfixed but might be a performance issue in rare situations involving very many calls to styled_format which don't GC). Calling SAFE_ALLOCA, while unsafe for GC (I'd suggest renaming the macro, but not right now), is safe wrt large allocations. >> feature/igc avoids all of these problems by keeping SDATA pointers >> valid, even when the string is resized. > > Unless the string is GC'ed, right? Even if it is GC'd. The SDATA will stay around while there are live pointers to it. The SDATA doesn't keep the string alive, but there's no way to get a reference to the now-dead Lisp_String structure from the SDATA, so this won't cause bugs. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 08:21:38 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 13:21:39 +0000 Received: from localhost ([127.0.0.1]:44164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbJcw-00080q-7w for submit@debbugs.gnu.org; Fri, 24 Jan 2025 08:21:38 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:58415) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbJct-00080X-7G for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 08:21:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737724888; x=1737984088; bh=4HEoZKhJQ111a6wNiV8X83XC3xGz3IoveVxDzMBDHT8=; 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=SYrU+7uYLMJRbmQG3IvhrLvEntJEtwljoLPBbfM2pkBKqe0+soIlQJWO7w5tN5Op3 wPpNDhB5s0VLrFtLU2eEjhwuLryZj9djsn9r3lTR/E6JqQXwXQEWutimb4GECgj/Xx 4N6M0XbJtiV5uz+v3/toFKZrJ8OGUGQ9i/L8n8lPmsx85iyykftM9lLKBQsVD0d/VM ntiPez7dWG/FsKHRSJPnrrQxOyyVAW9xo6Bm6XD9LKr2cW/1bmPG3VKUiSMWOx3gdn F9URkKNunweBgM7g8zntvfle9F14HTyPDecXgOmB7nEPALnnLRnxuVXr49KT765WDj JAij3Idlxouew== Date: Fri, 24 Jan 2025 13:21:24 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87sep8z6t2.fsf@protonmail.com> In-Reply-To: <86tt9oy7yc.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87msfh17is.fsf@protonmail.com> <86tt9oy7yc.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 919d857198b176894f4da43e89ffe6c637061877 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, Stefan Kangas 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: Thu, 23 Jan 2025 22:37:43 +0000 >> From: Pip Cet >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> > What did I miss? >> >> Can we make this a new bug? > > We could, or we could keep discussing that in this bug (since this is > still about styled_format). Let's do the latter, too much discussion happened here already and the subject does kind of cover this bug, too (as well as the excessive stack usage which remains unfixed; I cannot easily fix it without a lot of self-study or Paul Eggert's help). >> This one is SDATA, not SAFE_ALLOCA. >> >> diff --git a/src/editfns.c b/src/editfns.c >> index 4ba356d627c..23a5f9aeac6 100644 >> --- a/src/editfns.c >> +++ b/src/editfns.c >> @@ -3491,7 +3491,7 @@ styled_format (ptrdiff_t nargs, Lisp_Object *args,= bool message) >> /* If we start out planning a unibyte result, >> then discover it has to be multibyte, we jump back to retry. */ >> retry: >> - >> + format_start =3D SSDATA (args[0]); >> p =3D buf; >> nchars =3D 0; >> >> >> should fix it. > > Didn't try it yet, since we are still discussing what to do. But I > would like to install the test, for now as expected to fail. WDYT? Please don't. The test without the bugfix has absolutely undefined behavior and will most likely crash Emacs in some circumstances, and might cause other tests to produce incorrect results as well. Let's wait with adding such tests until we have ERT infrastructure to deal with them as gracefully as we can (crash tests need to be run in timeout, with a ulimit, so this involves Makefile work, too). (Stefan Kangas: I do recall you asked me to sketch how ERT changes could improve the output of "make check" in cases where Emacs crashed, in bug#75648. As Michael rejected the initial approach I had taken, I decided to delay this until I could make a new proposal that hadn't been rejected already. This bug now looks like it may result in one). Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 08:58:00 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 13:58:00 +0000 Received: from localhost ([127.0.0.1]:44229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbKC7-0001Eh-3C for submit@debbugs.gnu.org; Fri, 24 Jan 2025 08:57:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34740) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbKC3-0001EQ-EO for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 08:57:56 -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 1tbKBx-0006td-GG; Fri, 24 Jan 2025 08:57:49 -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=9/ggZfIBuOR0ggpXfMbHfZtMTCl5yeROwgHvW+D8e6M=; b=YNaPVOiZc/6cz3oeahJy HJ3BJZcMhJyk3o3ONq+4PdYkaZQ4s+jiWNoIrcPDLUKsNNuXLWQ0vDE9Xmfyl+n3pu/h/HdRXAK/+ 6JzZUdHpXmliM5bg38wUZPxlfOhtkwicIaQe7RVlq88mqD903iqrrwpWhgsJwNupSFBrPiNF6y+d2 08m3G7hYu7oiZApyTQ+PsXjZ+/ejtv86V5TRp/g8CrrPLC28Z/m+h6P2db2LvIBErcjYwzaLNo9BY +IdzIlVPZrkhufqLXoZAaFHsHZZZWDR/CFXj+poqKZurhwtylLpsA0cyZBjBwpgr9yioqx8fiG6uC zNjPAzAsq07KXA==; Date: Fri, 24 Jan 2025 15:57:45 +0200 Message-Id: <86bjvwxqjq.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <874j1o1ikj.fsf@protonmail.com> (message from Pip Cet on Fri, 24 Jan 2025 12:51:22 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <874j1o1ikj.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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 (---) > Date: Fri, 24 Jan 2025 12:51:22 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, Michael Albinus > > Michael Albinus, could you please C-s ert-how in this message and > comment briefly if appropriate? I think adding a new defstruct may help > improve ert in at least three ways, including this one. Please indicate > whether this would be *potentially* acceptable; if it is, I'll prepare a > separate bug. If it isn't, I might have to think of something else. I think it will take time for Michael to respond, due to his personal circumstances. So if you expect the answers soon, that might not happen. > "Eli Zaretskii" writes: > > >> Date: Thu, 23 Jan 2025 23:58:41 +0000 > >> From: Pip Cet > >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org > >> > >> 1. Reload format_start and format (and end, and format0) after every > >> call which might have GC'd. If you think we should do this, please > >> tell me whether lisp_string_width can GC. > > > > It can, if called with the last argument 'true' (because > > find_automatic_composition calls into Lisp). Currently, we call it > > with 'false', so it cannot. > > Is this documented anywhere? If you mean under what circumstances some internal function calls Lisp (or can otherwise GC), then no, we don't document that anywhere. I just looked at the source code to answer your question. > Thank you very much for suggesting this: if I hadn't been wrong about > the first test case being useful (it was), I'd probably have refused. > While writing this test didn't uncover new bugs, it was an educational > experience. > > New test: > > (ert-deftest editfns-tests-styled-print () > (let* ((gc-me (copy-sequence "foo")) > (print-unreadable-function > (lambda (&rest args) > (make-string 10 10 t) > (garbage-collect) > (make-string 10 10 t) > (prog1 (make-string 100 ?Ā t) > (setq gc-me nil) > (make-string 10 10 t)))) > (str "\"[1] ĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀ ĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀ ĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀĀ\"")) > (should (string= > (format "%S" (format (copy-sequence "%S %S %S %S") [1] > (symbol-function '+) > (symbol-function '*) > (symbol-function '-))) > str)))) > > The "problem" writing this test is that string compaction is very often > idempotent: the only way a string is moved again in a second GC is when > another string which is *older* than the string moved in the first GC is > freed. That's 'gc-me', which must be live during the first call to > garbage-collect but unreachable for the second call. I suggest to have at least part of the above in comments to the test, since these details are so important for the test to be effective. > While I figured out how to do this for this specific test, it'd be nicer > to just run make check-gc and stress-test the garbage collector in ways > known to have caused problems. Yes; patches welcome. > (Brief proposal relevant to several issues: If we want to test GC bugs > more thoroughly, we need a way to tell ert to run them in a special way. > I proposed extending ert with an ert-how defstruct for the make > benchmark target, indicating "how" a test is to be run, and implemented > it, but I don't think I've sent the patch yet. Using this structure to > create conditions for testing for GC bugs would be possible, and it > would also be an easier way to make crash tests print a message before > they're run. > > Of course, this would in no way imply a decision to use this structure, > or ERT, for "make benchmark". Using it for GC testing or indicating > crash tests would be sufficient reason to add it, IMHO. > > While this needs more thought, if it's obviously unacceptable for a > simple reason I haven't thought of, please let me know so I won't waste > time on it. Of course the final decision will have to be made based on > an actual patch, but if we can have a quick "no" right now I'd > appreciate it.) Well, for now I don't have even a vague idea what you have in mind, so it is hard for me to answer the question. How do you extend ERT to be able to run tests in a way that makes testing GC-related bugs easier? What are the general ideas for that? > >> + char *format_start = SAFE_ALLOCA (formatlen); > >> + memcpy (format_start, SSDATA (args[0]), formatlen); > >> bool fmt_props = !!string_intervals (args[0]); > > > > Does this assume anything about formatlen, like that it doesn't exceed > > the alloca limit? If so, should we have an assertion about that? > > No. We're already past the alloca limit at his point so SAFE_ALLOCA > will always call xmalloc here (that's the "excessive stack usage" part > of this bug, which remains unfixed but might be a performance issue in > rare situations involving very many calls to styled_format which don't > GC). IMO, that fact should also be in comments to the code. > >> feature/igc avoids all of these problems by keeping SDATA pointers > >> valid, even when the string is resized. > > > > Unless the string is GC'ed, right? > > Even if it is GC'd. > > The SDATA will stay around while there are live pointers to it. The > SDATA doesn't keep the string alive, but there's no way to get a > reference to the now-dead Lisp_String structure from the SDATA, so this > won't cause bugs. Even if the code modifies the string after GC? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 09:09:43 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 14:09:43 +0000 Received: from localhost ([127.0.0.1]:44255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbKNS-0001kX-Ok for submit@debbugs.gnu.org; Fri, 24 Jan 2025 09:09:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39880) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbKNQ-0001kK-J0 for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 09:09:41 -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 1tbKNI-0008FY-VW; Fri, 24 Jan 2025 09:09:34 -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=lAh9cFEOaxrEuX/oHrFvBCiF0qaTG8TlyKLveTYtFt0=; b=VA7erC90Mi+2 dyG1mJu0wkn59BKdtokXkt3V0Ox2aj98HzGs+37isUUhl90+CveLMKDB0UTxOVO3OBWl9tOuS5ni5 gdBqOsFipkJlKHKX/QOZ54hjXr93ty1caFlKFKwuyVCGmWO6ISFyIgz/B+EebTu8FoIrAenC6a9eK DpcPwc1TTryHooK1zO7CkmwEGqV/K61/pw1B/suFCVMQ5XwPOT7lN1btfmdW/P7m70YIvp92GGzYD 1do0A52KHjoQg9XfcsUpZm7DIFZKnIf4PXrxDi6LAt8oHz7RqLExCIm7pQ0YtvC0NzKU6gwTiQ1Kv cEcgVnN9/xw8aB3cIWatJA==; Date: Fri, 24 Jan 2025 16:09:05 +0200 Message-Id: <867c6kxq0u.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87sep8z6t2.fsf@protonmail.com> (message from Pip Cet on Fri, 24 Jan 2025 13:21:24 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87msfh17is.fsf@protonmail.com> <86tt9oy7yc.fsf@gnu.org> <87sep8z6t2.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, stefankangas@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: -3.3 (---) > Date: Fri, 24 Jan 2025 13:21:24 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, Stefan Kangas > > "Eli Zaretskii" writes: > > >> Can we make this a new bug? > > > > We could, or we could keep discussing that in this bug (since this is > > still about styled_format). > > Let's do the latter Fine by me. However, ... > (Stefan Kangas: I do recall you asked me to sketch how ERT changes could > improve the output of "make check" in cases where Emacs crashed, in > bug#75648. As Michael rejected the initial approach I had taken, I > decided to delay this until I could make a new proposal that hadn't been > rejected already. This bug now looks like it may result in one). ... _this_ part definitely belongs to a separate discussion, probably on emacs-devel and not here. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 10:02:40 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 15:02:40 +0000 Received: from localhost ([127.0.0.1]:46530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbLCh-0004vL-FI for submit@debbugs.gnu.org; Fri, 24 Jan 2025 10:02:40 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:42097) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbLCe-0004uy-3N for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 10:02:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737730948; x=1737990148; bh=4F4T6yYDwF8fZ4CbvRRgyDA5wKte92/97IISFj5gZXo=; 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=DKRRr4OT6b3hFTgk20CyAfncl+PW94uP0lIQ6iFq9WYehweJcRru/BonbJJ8/7pDE Su9QVcQi8b/x3juAd6o9nuoYevLFr+PFu/lzEKaywK9JgjOoD5avTwsHt9JUQn9Scb /lnVB+mLXS5oaa1g08XgBtO3hJ6P4JckKBpcHgm1f4itc4+PWPRbQ7TT/D9mC2/gv0 Rq5K/ylxImD0xqqYrTjVba10OJTmdSnIUd1zDSlIW6E/QHXe49bXmSTgF6sLDLIZCh Z7CKy7ieC2J+DQ91L46+1KDwpWmQZA+zKJLO05KtEDyuzuam5cTSRSGxFyRMk2kUwC Zzuh1ri1PipTA== Date: Fri, 24 Jan 2025 15:02:20 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87a5bgxnkg.fsf@protonmail.com> In-Reply-To: <86bjvwxqjq.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <874j1o1ikj.fsf@protonmail.com> <86bjvwxqjq.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b5d9c04bebf0c7644a5bcb33a861b07c4ff5e2ed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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: -1.0 (-) "Eli Zaretskii" writes: >> Date: Fri, 24 Jan 2025 12:51:22 +0000 >> From: Pip Cet >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, Michael Albinus >> >> Michael Albinus, could you please C-s ert-how in this message and >> comment briefly if appropriate? I think adding a new defstruct may help >> improve ert in at least three ways, including this one. Please indicate >> whether this would be *potentially* acceptable; if it is, I'll prepare a >> separate bug. If it isn't, I might have to think of something else. > > I think it will take time for Michael to respond, due to his personal > circumstances. So if you expect the answers soon, that might not > happen. Will file a new bug, with an initial message hopefully clear enough to save Michael some time for when he gets around to it. >> "Eli Zaretskii" writes: >> >> >> Date: Thu, 23 Jan 2025 23:58:41 +0000 >> >> From: Pip Cet >> >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org >> >> >> >> 1. Reload format_start and format (and end, and format0) after every >> >> call which might have GC'd. If you think we should do this, please >> >> tell me whether lisp_string_width can GC. >> > >> > It can, if called with the last argument 'true' (because >> > find_automatic_composition calls into Lisp). Currently, we call it >> > with 'false', so it cannot. >> >> Is this documented anywhere? > > If you mean under what circumstances some internal function calls Lisp > (or can otherwise GC), then no, we don't document that anywhere. I > just looked at the source code to answer your question. (This is an honest question: do you believe Emacs would be worse off if we added an ASSUME_NO_GC macro like ASSUME_NO_GC (true); p =3D SDATA (str); 532 lines of code here use p for the last time ASSUME_NO_GC (false); This seems to me to be readable (better names/API welcome, of course), even if it's a nop. Faster than writing down these assumptions in English, and it does offer the ability to eventually find such cases automatically. That would have found this bug if Fprin1 contained /* Due to print-unreadable-function, all calls to prin1 may call Lisp, which may GC. Ensure we're not accidentally called from a critical section. */ #ifdef ENABLE_CHECK_NO_GC if (assume_no_gc >=3D 0) emacs_abort (); #endif It'd make life easier for relative Emacs newcomers like myself who do not know by heart which functions call GC and which don't.) >> Thank you very much for suggesting this: if I hadn't been wrong about >> the first test case being useful (it was), I'd probably have refused. >> While writing this test didn't uncover new bugs, it was an educational >> experience. >> >> New test: >> >> (ert-deftest editfns-tests-styled-print () >> (let* ((gc-me (copy-sequence "foo")) >> (print-unreadable-function >> =09 (lambda (&rest args) >> (make-string 10 10 t) >> (garbage-collect) >> (make-string 10 10 t) >> (prog1 (make-string 100 ?=C4=80 t) >> (setq gc-me nil) >> (make-string 10 10 t)))) >> (str "\"[1] =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80 =C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80= =C4=80 =C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4=80=C4= =80=C4=80=C4=80=C4=80=C4=80=C4=80\"")) >> (should (string=3D >> (format "%S" (format (copy-sequence "%S %S %S %S") [1] >> (symbol-function '+) >> (symbol-function '*) >> (symbol-function '-))) >> str)))) >> >> The "problem" writing this test is that string compaction is very often >> idempotent: the only way a string is moved again in a second GC is when >> another string which is *older* than the string moved in the first GC is >> freed. That's 'gc-me', which must be live during the first call to >> garbage-collect but unreachable for the second call. > > I suggest to have at least part of the above in comments to the test, > since these details are so important for the test to be effective. Yes, definitely, if it is to be useful. Without comments this is so much line noise. > What are the general ideas for that? This doesn't belong here; I'll file a new bug even if I can't provide such details now (unless there already is one), as a wishlist item. >> >> feature/igc avoids all of these problems by keeping SDATA pointers >> >> valid, even when the string is resized. >> > >> > Unless the string is GC'ed, right? >> >> Even if it is GC'd. >> >> The SDATA will stay around while there are live pointers to it. The >> SDATA doesn't keep the string alive, but there's no way to get a >> reference to the now-dead Lisp_String structure from the SDATA, so this >> won't cause bugs. > > Even if the code modifies the string after GC? If the GC free'd the string, but not the SDATA structure, we cannot regenerate the string to call resize_string_data. So, no, this cannot happen. Note that resizing a live string while you have a live SDATA pointer to it might result in the SDATA pointer referring to the pre-modification SDATA, not the current one. Thanks for continuing to ask such questions! It's important we don't forget about one such question and cause crashes, particularly on feature/igc where there's a shortage of testers (which is not anyone's fault but mine; I'm working on making it more testable)! Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 10:29:08 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 15:29:08 +0000 Received: from localhost ([127.0.0.1]:46568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbLcJ-00066O-Tg for submit@debbugs.gnu.org; Fri, 24 Jan 2025 10:29:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40386) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbLcG-00065r-4u for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 10:29:06 -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 1tbLcA-0002mM-0K; Fri, 24 Jan 2025 10:28:58 -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=RESt9abQqJqYpDo7n+imYOdVDduV1N0beX2RuGKQyOM=; b=rMlkozyxF5+6 LYlKLMrymz4m7csCXqw7nLw/90Ga2D7rJMx16g7NrRUJ/6NI5Oz2nMrNReEbReVF7YvsBPoQxRcQ9 rVv/DYsef4NrxfWbXueKLhZ4kwBn+/i6SwTPZcMXCsY+GtC3PK59yDtmYhRfQwgX2BqQTIRqkxzrt 9RepwLSVhiDfFMnhpmQ2/NOMoYmqD326R5cBTb/nZjPuT7FHHaV7RQOwxRA3OMHvg5enu5LNsMQPF MoriseGyko8gSDGuRBNtcdDSLqfQCuCjI8xeudmurIpyyWYM13ccLrraTLZt3WpwJtKOPre4AruO0 fsuNkkxlN2n9ojzu3wWTEw==; Date: Fri, 24 Jan 2025 17:28:53 +0200 Message-Id: <865xm4xmbu.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87a5bgxnkg.fsf@protonmail.com> (message from Pip Cet on Fri, 24 Jan 2025 15:02:20 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <874j1o1ikj.fsf@protonmail.com> <86bjvwxqjq.fsf@gnu.org> <87a5bgxnkg.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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 (---) > Date: Fri, 24 Jan 2025 15:02:20 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org, michael.albinus@gmx.de > > > If you mean under what circumstances some internal function calls Lisp > > (or can otherwise GC), then no, we don't document that anywhere. I > > just looked at the source code to answer your question. > > (This is an honest question: do you believe Emacs would be worse off if > we added an ASSUME_NO_GC macro like > > ASSUME_NO_GC (true); > p = SDATA (str); > > 532 lines of code here > > use p for the last time > > ASSUME_NO_GC (false); No, I don't think Emacs will be worse. But I hope we will only have to do this in not too-many places. Although I'm unsure how to find them and how to discern between them and the rest. We'd need some rules where to place these. > >> >> feature/igc avoids all of these problems by keeping SDATA pointers > >> >> valid, even when the string is resized. > >> > > >> > Unless the string is GC'ed, right? > >> > >> Even if it is GC'd. > >> > >> The SDATA will stay around while there are live pointers to it. The > >> SDATA doesn't keep the string alive, but there's no way to get a > >> reference to the now-dead Lisp_String structure from the SDATA, so this > >> won't cause bugs. > > > > Even if the code modifies the string after GC? > > If the GC free'd the string, but not the SDATA structure, we cannot > regenerate the string to call resize_string_data. So, no, this cannot > happen. > > Note that resizing a live string while you have a live SDATA pointer to > it might result in the SDATA pointer referring to the pre-modification > SDATA, not the current one. Who said anything about resizing? I thought about changing a string with SSET, for example, or Faset. IOW, the scenario is: . we take a pointer to a string's SDATA . GC happens . we use SSET or Faset to modify the string . we use the above pointer With the old GC, this is a no-no, but you seem to be saying that on the igc branch it's okay to do that? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 24 18:40:55 2025 Received: (at 75754) by debbugs.gnu.org; 24 Jan 2025 23:40:55 +0000 Received: from localhost ([127.0.0.1]:47610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbTIF-0002VY-Hw for submit@debbugs.gnu.org; Fri, 24 Jan 2025 18:40:55 -0500 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]:53511) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tbTID-0002VG-LA for 75754@debbugs.gnu.org; Fri, 24 Jan 2025 18:40:54 -0500 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-aaef00ab172so438003366b.3 for <75754@debbugs.gnu.org>; Fri, 24 Jan 2025 15:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737762047; x=1738366847; 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=dbK576VvAqI/zbaXSwJGbkNuh8jgD6xUeqqXU5JVb2A=; b=DG0jYy2HPedC3TMzME2+n7L/YBQEnyYE5mumksYhOYP1w7xRfcFEUK2K75Q7uTigPL 6Z5N9zezVchdvG5dPjAgCVJu3wuH3grNfdZw/DeJ81P/3ptJdKRvYD0z3g1GV5j+kTnF gZaTR7swYODGGuEF6jvY9IjTtycQQpG9pZbRATuWQSfoFYOblWTay4fQDzpextV6pQ52 Wzj2ud13xjFBB16tAkSqzhiXkgWuwqtFXQmTWzHKIleipC+ZoSUW1ByQ+8nm8f2gOyk/ sxDbnGzkSuZIoMgEcIyXPRSrqGC4Ie3oIzFNiGj9HqyT5iAYjHOvVYAkR5InbdzWPsWI Z8qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737762047; x=1738366847; 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=dbK576VvAqI/zbaXSwJGbkNuh8jgD6xUeqqXU5JVb2A=; b=DKp7FCh25oOtNCBGmxzbcnqZSX5gre1OmueFgH/ITSuPm73czueJTK/nBRp5SJspKb IKvw5E4zAC1g9MyCkEJ1p6MgBA4cOn3mSLeHwiDmPuUoCTAxzooAQ2LOtDszmfr+hPGo JoXJCnQebMJvDCl9IgajtRujbrl4f+DYTGmyC02GfMpKn54WuCKL+mNUDgnAMWGGr6LA OV8Udwfnnsr3hrtzh9AMmPmT8pehAtnIGHLCMdjGvfrHRvgp8DS9LJuC+dfvR1ipayr/ RW4BvdSfN5hcOa5k0XqBevkBWa19wDUhwq51oCWdRf+zzBi57IbTWhp8RknDMBFXG7tg +3Ug== X-Forwarded-Encrypted: i=1; AJvYcCVtZHY54OaRZcaxZSFOZuiipYItcwJXOafA1uN4CgOeW5+tLqETYNd0UoHpTXPgTzbqfQPFSA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwziC2X39QCQ77MSk1O2C933mJzH8RBA+MRkij4oNZisImklcrB 5q2rAtUSguUJafJ7GZsvia2GhYY2CCPdWKOzirY59AhFk0xwSyJmw0/w22qqpZgkgVNJRt6EMu/ Y3yzO+pg0azcx9wyWky8ZeE53ZGE= X-Gm-Gg: ASbGncvM6FlWjptMRJiLmolXvrEd+YT1IXnhCnD+K4w0xk583woRXYfd8/aK/jRTupL +dAN+WEl6Zs4Gimef7fJ6wdh4HDlHWPT0Z7nGJXhqoVR86xTEFb6se7gAHtZAVNQ= X-Google-Smtp-Source: AGHT+IEw5ckYky7ZO0+Gmk25YowBG0BF9Io3qBUDWABjRlmD2IwGVe0S+UCDtmlM/GMY2j80rKUEVsbbWgiQIGsLg7s= X-Received: by 2002:a05:6402:26c9:b0:5da:1219:c81 with SMTP id 4fb4d7f45d1cf-5db7d300633mr74187901a12.16.1737762047153; Fri, 24 Jan 2025 15:40:47 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 24 Jan 2025 17:40:46 -0600 From: Stefan Kangas In-Reply-To: <867c6kxq0u.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87msfh17is.fsf@protonmail.com> <86tt9oy7yc.fsf@gnu.org> <87sep8z6t2.fsf@protonmail.com> <867c6kxq0u.fsf@gnu.org> MIME-Version: 1.0 Date: Fri, 24 Jan 2025 17:40:46 -0600 X-Gm-Features: AWEUYZn0wwx2sUQyk3l53fuj7qI5yK8bByf4tOIpz4vP-I3DILE7Zxsgg6r3U5g Message-ID: Subject: Re: bug#75754: styled_format stack usage/GC protection To: Eli Zaretskii , Pip Cet Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, 75754@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: -1.0 (-) Eli Zaretskii writes: >> (Stefan Kangas: I do recall you asked me to sketch how ERT changes could >> improve the output of "make check" in cases where Emacs crashed, in >> bug#75648. As Michael rejected the initial approach I had taken, I >> decided to delay this until I could make a new proposal that hadn't been >> rejected already. This bug now looks like it may result in one). > > ... _this_ part definitely belongs to a separate discussion, probably > on emacs-devel and not here. Moving this to emacs-devel sounds good to me. I think improving this aspect would be generally useful, so thanks for working on it. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 02:55:10 2025 Received: (at 75754) by debbugs.gnu.org; 25 Jan 2025 07:55:10 +0000 Received: from localhost ([127.0.0.1]:48299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbb0X-0007JC-9x for submit@debbugs.gnu.org; Sat, 25 Jan 2025 02:55:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54058) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbb0U-0007Ed-T6 for 75754@debbugs.gnu.org; Sat, 25 Jan 2025 02:55:08 -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 1tbb0O-0003Xv-E3; Sat, 25 Jan 2025 02:55:00 -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=pCTjDSahxGLm5+1vtJKS5tAsKKaXIySDgkaXF7Yh1Eg=; b=F3J6vu8oRnUk TkrEIxItExe5BDauWDDpk8mWRhCcwqDDpnOdIIuytrpsMiVf6Mg8V4pwGrvzQtD3XCsQc1NZn0u+9 YehhUqyGfW4d7xcq9ShtkF45ge4vX4qnS7R98FD3Ogwlft5Xn5KsZBHpIV5ug9IeYky1XCJ/yPLad xTY2DmvAQ22hh6vILkBbG5myDEHsl8RiUxbyRwWQTn+SFUykPQnG3MBA/MEYHidUZk66Jy7SYBIxu NLh/nproZJnLSgEyXQn+WgdSVuC32qKFhlfcjeZyg2QWjWQxL/h0qzqwqEqca4uU9j79k69t/bP3p sr25YsFEeXCCPD2Z/x36dA==; Date: Sat, 25 Jan 2025 09:54:58 +0200 Message-Id: <86sep7wcod.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87jzajvo06.fsf@protonmail.com> (message from Pip Cet on Fri, 24 Jan 2025 22:35:50 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <874j1o1ikj.fsf@protonmail.com> <86bjvwxqjq.fsf@gnu.org> <87a5bgxnkg.fsf@protonmail.com> <865xm4xmbu.fsf@gnu.org> <87h65ow0uq.fsf@protonmail.com> <86wmekvz5q.fsf@gnu.org> <87jzajvo06.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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 (---) > Date: Fri, 24 Jan 2025 22:35:50 +0000 > From: Pip Cet > > >> I think we should eventually strive to call these macros in all but the > >> most obviously correct places where we use SDATA: > >> > >> memcpy (buf, SDATA (str), SBYTES (str)); > >> > >> is perfectly okay, but the current code in call_process is not, and we > >> can (IF we find bugs; most of my experiments don't, and that's okay) > >> decide where to draw the line between those. > > > > I won't have an opinion until I actually see the patches. > > Understood. > > >> My preference would be to store the "no-gc" nesting level in the specpdl > >> directly rather than allocating a new specpdl entry every time we > >> increase it. We definitely do unwind out of no-gc situations, in any > >> case, which is fine. > >> > >> (The alternative would be to call SDATA_FREE on sdata pointers when > >> we're done with them, but that seems excessive to me at this point, > >> particularly since we'd need to unwind that, too.) > > > > You lost me here. > > We could demand that every SDATA call be balanced by an SDATA_FREE call > or a nonlocal exit. > > At this point, I don't think we should, because there are other no-GC > assertions and we've seen where "technically necessary but usually nop" > macros got us with GCPRO. > > I think we'll have to ultimately have to find a compromise, for the old > GC, between reducing no-GC situations and asserting we're in one when we > need to be. If stack references pin SDATA and we scan SAFE_ALLOCA'd > memory conservatively, that would still leave SDATA pointers in > explicitly xmalloc'd memory, and temporarily invalid objects that would > crash the garbage collector if it were to look at them. Maybe more > situations. > > Note these proposals interact non-trivially. > > However, I think we should try hard to keep this as non-intrusive as > possible. ASSUME_NO_GC (); seems okay to me to mark the start of a > no-GC section, but ASSUME_NO_GC (true) balanced by ASSUME_NO_GC (false) > already feels like I'm doing the compiler's work for it, even if an > xsignal non-local exit implies the right numbers of ASSUME_NO_GC (false) > calls: the vast majority of critical sections begin and end in the same > function, and any early return means we've left the critical section. > > However, if we decided to make "return" imply an ASSUME_NO_GC reset, > that, while possible, would probably introduce system dependencies we > might not be able to accept easily. > > I don't know whether most functions that call SDATA have a critical > section which ends before the function returns. You seem to be discussing some details of the ASSUME_NO_GC macro implementation. I cannot follow this because I don't have a clear enough idea of what you have in mind, and you didn't yet describe the main ideas of the implementation. So let's defer this until you do. > >> >> > Even if the code modifies the string after GC? > >> >> > >> >> If the GC free'd the string, but not the SDATA structure, we cannot > >> >> regenerate the string to call resize_string_data. So, no, this cannot > >> >> happen. > >> >> > >> >> Note that resizing a live string while you have a live SDATA pointer to > >> >> it might result in the SDATA pointer referring to the pre-modification > >> >> SDATA, not the current one. > >> > > >> > Who said anything about resizing? > >> > >> Non-resizing Faset is boring, works as expected. > > > > But it will modify the string whose SDATA pointer is different, no? > > Different how? Different as in: "pointing to a location different from the data of the string that was moved by GC". > There's only one string in this example, and after the > string's SDATA changes, you can access the old SDATA, but it doesn't > belong to a string anymore. That's what I thought. So code that expects the old SDATA pointer to be pointing to the same string after GC will have a bug on the igc branch. It's a different bug than under the old GC, but still a bug. Right? > > Lisp_Object my_string; > > char *p = SDATA (my_string); > > /* trigger GC */ > > Faset (my_string, make_fixnum (0), make_fixnum (97)); > > /* code which expects p[0] to be 'a' */ > > If that is all the code, this is safe with feature/igc. You say "safe", but it sounds like we have different definitions of "safe". Because later you say: > MPS GC will never make pointers that live on the stack invalid. It's > transparent to correct client programs. So, yes, if you're asking about > MPS GC, the sequence is safe and doesn't crash, but may surprise you by > reproducing the old string data. Which seems to mean your "safe" means the code will not crash, whereas what I meant is the correctness of the code. Code which refers to the old string data is incorrect, even if it won't crash. So my conclusion is that even with MPS, referring in code after GC to an SDATA pointer taken before GC leads to incorrect code. IOW, pointers to SDATA of a string cannot be relied upon to be valid (i.e. pointing to the correct string) across GC, so the code must re-initialize such pointer after any fragment that could GC. This was the rule with the old GC, and it should continue to be the rule with MPS. > >> > With the old GC, this is a no-no, but you seem to be saying that on > >> > the igc branch it's okay to do that? > >> > >> Note that none of that is guaranteed. We might poison the old SDATA in > >> Faset, and possibly should. I don't think MPS officially allows you to > >> prematurely free an object, so that's probably not going to happen. > > > > Is that a yes? > > It's currently safe. "Safe" as in "won't crash" or "safe" as in "will point to the correct string data"? I think the former, whereas I was talking about the latter. > One scenario is we decide that no useful code > wants to do this, so we deliberately make it crash if we can. Another > scenario is that we decide this is so useful that we add an > SDATA->struct Lisp_String back pointer (alloc.c goes both ways, giving > you a back pointer but moving it around in memory so it'll be invalid > should you ever need it). As both of these scenarios require > significant work and a lot of thought, it's most likely the current > situation persists on feature/igc for a while, and no great loss either > way. That's not the issue that was bothering me. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 04:45:31 2025 Received: (at 75754) by debbugs.gnu.org; 25 Jan 2025 09:45:32 +0000 Received: from localhost ([127.0.0.1]:48542 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbcjL-00020p-Cx for submit@debbugs.gnu.org; Sat, 25 Jan 2025 04:45:31 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:15475) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbcjJ-00020T-BG for 75754@debbugs.gnu.org; Sat, 25 Jan 2025 04:45:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737798322; x=1738057522; bh=Zj/XmMMX46OYi/Qj6XYZE7UR1X0HRcH933lHkWLLbVY=; 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=kp5lyYxfIxV0oenFyHjPLTP2Pdrs3ujdLEd91cT5P+DAHMhaRfK8AN0PZwJJ13NRf xVlLTq7aprqufDpzUgO0NFp5yud6PmDekOoObhJh65dMR8ZL6i3cKdMd6/Ujtp4Pn/ n5Yq2M8EPDkdhqc87VTCNLPAllTPB0sdZCo1bxOgMOzQ2QXLJaTVyTJCHHEnAfQAsE TcPvv/I4A0LvIovnk7EXJK7XCQjKipkuhjUSeRf/fKhOoxkjmZgwOO+Z3ySwk7ok+B LxsGY9gObiUywLQYI5XZwXST0oM0i0VRDSlZY9GslP4X1c1D/02gui0NhHhbjI10gC m9zgXBjEFbQpg== Date: Sat, 25 Jan 2025 09:45:19 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87o6zvtefz.fsf@protonmail.com> In-Reply-To: <86sep7wcod.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <874j1o1ikj.fsf@protonmail.com> <86bjvwxqjq.fsf@gnu.org> <87a5bgxnkg.fsf@protonmail.com> <865xm4xmbu.fsf@gnu.org> <87h65ow0uq.fsf@protonmail.com> <86wmekvz5q.fsf@gnu.org> <87jzajvo06.fsf@protonmail.com> <86sep7wcod.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0c1387b1f476a02197a1cf12fc38947762e5eefa MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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: -1.0 (-) "Eli Zaretskii" writes: >> Date: Fri, 24 Jan 2025 22:35:50 +0000 >> From: Pip Cet >> >> >> > Even if the code modifies the string after GC? >> >> >> >> >> >> If the GC free'd the string, but not the SDATA structure, we canno= t >> >> >> regenerate the string to call resize_string_data. So, no, this ca= nnot >> >> >> happen. >> >> >> >> >> >> Note that resizing a live string while you have a live SDATA point= er to >> >> >> it might result in the SDATA pointer referring to the pre-modifica= tion >> >> >> SDATA, not the current one. >> >> > >> >> > Who said anything about resizing? >> >> >> >> Non-resizing Faset is boring, works as expected. >> > >> > But it will modify the string whose SDATA pointer is different, no? >> >> Different how? > > Different as in: "pointing to a location different from the data of > the string that was moved by GC". I'm sorry, this may sound like you as though I'm being pedantic, but I need to be sure that we're talking about the same thing here: The scenario you describe involves a single string object, but two sdata areas. The single string points to the first sdata area, but then is modified to point to the second. Modifying the first sdata area after the second one has been created will have no effect whatsoever on the string. >> There's only one string in this example, and after the >> string's SDATA changes, you can access the old SDATA, but it doesn't >> belong to a string anymore. > > That's what I thought. So code that expects the old SDATA pointer to > be pointing to the same string after GC will have a bug on the igc feature/igc: GC doesn't invalidate SDATA pointers. Resizing string modification does (the other way is to call pin_string). > branch. It's a different bug than under the old GC, but still a bug. > Right? If there's modification involved, it's a bug which will cause apparently random behavior but no crashes. If there's no modification, it's a bug only because the code might be used with alloc.c GC. >> > Lisp_Object my_string; >> > char *p =3D SDATA (my_string); >> > /* trigger GC */ >> > Faset (my_string, make_fixnum (0), make_fixnum (97)); >> > /* code which expects p[0] to be 'a' */ >> >> If that is all the code, this is safe with feature/igc. > > You say "safe", but it sounds like we have different definitions of > "safe". Because later you say: I meant "won't crash, but most likely useless". >> MPS GC will never make pointers that live on the stack invalid. It's >> transparent to correct client programs. So, yes, if you're asking about >> MPS GC, the sequence is safe and doesn't crash, but may surprise you by >> reproducing the old string data. > > Which seems to mean your "safe" means the code will not crash, whereas > what I meant is the correctness of the code. Code which refers to the > old string data is incorrect, even if it won't crash. I believe that's true. > So my conclusion is that even with MPS, referring in code after GC to > an SDATA pointer taken before GC leads to incorrect code. IOW, > pointers to SDATA of a string cannot be relied upon to be valid > (i.e. pointing to the correct string) across GC, so the code must > re-initialize such pointer after any fragment that could GC. This was > the rule with the old GC, and it should continue to be the rule with > MPS. No. GC doesn't invalidate SDATA pointers. Only string resizing does (but that's a technical detail: code should assume all string modification may resize the string, and always reload any SDATA pointers they might have). The only reason such code must be buggy is because it will fail to work with alloc.c. In some (rare) cases, we're fine with the undefined behavior: if we call out to Lisp code which unexpectedly modifies a string we're currently looking at, we shouldn't crash (this is hard for multibyte strings), but we shouldn't go out of our way to detect or handle this situation, either. (I posted a patch yesterday to fix mapconcat in this case, and it does precisely that: if we find ourselves in the middle of a multibyte sequence unexpectedly, that's an error(), not a crash. The patch does need an additional small change I'd overlooked). My proposal is to reload the SDATA pointer even in such cases, so it's more obvious that there is no bug in our code then. If we decide to establish that rule, we may also want to enforce it. Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 08:24:10 2025 Received: (at 75754) by debbugs.gnu.org; 25 Jan 2025 13:24:10 +0000 Received: from localhost ([127.0.0.1]:48921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbg8w-0007fJ-0g for submit@debbugs.gnu.org; Sat, 25 Jan 2025 08:24:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53432) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbg8s-0007eb-7z for 75754@debbugs.gnu.org; Sat, 25 Jan 2025 08:24:08 -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 1tbg8l-0003DL-L6; Sat, 25 Jan 2025 08:23:59 -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=sI6HPRKfm3r94iMXne3zBdMTYZCUmI058hg6LhV3Fvs=; b=bJA0E1jxvFWC 4+iQIeRISOa+C4MMLoCA6lm+JfPNGHWnRPRxGWVOXzzK4rpJd3Ule54pkREYUHN/1AbqyQBDUTOHk vz6nmBmAppYK7W3tD8BALMoazd/z+4vyK5y561cTpMnuK05x7SMR6LkUTUfo5vRSSaUXRxDpGMc8L E2wnB45x/vseF7939zd4+ZsJZFo75YtoRRff5murLDly0/bxtlEMpIuFR0CqloD/J13AOP1ymzZ8V xmSeraLcqxvaMKJqy0qLFR0El7839l3awMFlMHykJUXO+YywgXi3EUveoxWYmZ3Y0HPYnZ+jYgkr5 smbbt6v+E4+3N1ZSi55fFw==; Date: Sat, 25 Jan 2025 15:23:56 +0200 Message-Id: <868qqzuivn.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87o6zvtefz.fsf@protonmail.com> (message from Pip Cet on Sat, 25 Jan 2025 09:45:19 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <874j1o1ikj.fsf@protonmail.com> <86bjvwxqjq.fsf@gnu.org> <87a5bgxnkg.fsf@protonmail.com> <865xm4xmbu.fsf@gnu.org> <87h65ow0uq.fsf@protonmail.com> <86wmekvz5q.fsf@gnu.org> <87jzajvo06.fsf@protonmail.com> <86sep7wcod.fsf@gnu.org> <87o6zvtefz.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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 (---) > Date: Sat, 25 Jan 2025 09:45:19 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> Date: Fri, 24 Jan 2025 22:35:50 +0000 > >> From: Pip Cet > > >> >> >> > Even if the code modifies the string after GC? > >> >> >> > >> >> >> If the GC free'd the string, but not the SDATA structure, we cannot > >> >> >> regenerate the string to call resize_string_data. So, no, this cannot > >> >> >> happen. > >> >> >> > >> >> >> Note that resizing a live string while you have a live SDATA pointer to > >> >> >> it might result in the SDATA pointer referring to the pre-modification > >> >> >> SDATA, not the current one. > >> >> > > >> >> > Who said anything about resizing? > >> >> > >> >> Non-resizing Faset is boring, works as expected. > >> > > >> > But it will modify the string whose SDATA pointer is different, no? > >> > >> Different how? > > > > Different as in: "pointing to a location different from the data of > > the string that was moved by GC". > > I'm sorry, this may sound like you as though I'm being pedantic, but I > need to be sure that we're talking about the same thing here: > > The scenario you describe involves a single string object, but two sdata > areas. The single string points to the first sdata area, but then is > modified to point to the second. Modifying the first sdata area after > the second one has been created will have no effect whatsoever on the > string. > > >> There's only one string in this example, and after the > >> string's SDATA changes, you can access the old SDATA, but it doesn't > >> belong to a string anymore. > > > > That's what I thought. So code that expects the old SDATA pointer to > > be pointing to the same string after GC will have a bug on the igc > > feature/igc: GC doesn't invalidate SDATA pointers. Resizing string > modification does (the other way is to call pin_string). > > > branch. It's a different bug than under the old GC, but still a bug. > > Right? > > If there's modification involved, it's a bug which will cause apparently > random behavior but no crashes. If there's no modification, it's a bug > only because the code might be used with alloc.c GC. > > >> > Lisp_Object my_string; > >> > char *p = SDATA (my_string); > >> > /* trigger GC */ > >> > Faset (my_string, make_fixnum (0), make_fixnum (97)); > >> > /* code which expects p[0] to be 'a' */ > >> > >> If that is all the code, this is safe with feature/igc. > > > > You say "safe", but it sounds like we have different definitions of > > "safe". Because later you say: > > I meant "won't crash, but most likely useless". > > >> MPS GC will never make pointers that live on the stack invalid. It's > >> transparent to correct client programs. So, yes, if you're asking about > >> MPS GC, the sequence is safe and doesn't crash, but may surprise you by > >> reproducing the old string data. > > > > Which seems to mean your "safe" means the code will not crash, whereas > > what I meant is the correctness of the code. Code which refers to the > > old string data is incorrect, even if it won't crash. > > I believe that's true. The above confirms what I thought about this, thanks. > > So my conclusion is that even with MPS, referring in code after GC to > > an SDATA pointer taken before GC leads to incorrect code. IOW, > > pointers to SDATA of a string cannot be relied upon to be valid > > (i.e. pointing to the correct string) across GC, so the code must > > re-initialize such pointer after any fragment that could GC. This was > > the rule with the old GC, and it should continue to be the rule with > > MPS. > > No. And this seems to contradict it. > GC doesn't invalidate SDATA pointers. I never said anything about invalidating the SDATA pointers. So if your "No" is because of the (lack of) invalidation, then it is not relevant to what I was asking about. Code can be incorrect even if it doesn't crash or otherwise refers to invalid pointers. It could be incorrect because it modifies incorrect memory believing that it modifies the data of a string. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 13:20:56 2025 Received: (at 75754) by debbugs.gnu.org; 25 Jan 2025 18:20:56 +0000 Received: from localhost ([127.0.0.1]:52510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tbkm8-0006XY-0s for submit@debbugs.gnu.org; Sat, 25 Jan 2025 13:20:56 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:39333) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tbkm4-0006XA-Et for 75754@debbugs.gnu.org; Sat, 25 Jan 2025 13:20:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1737829245; x=1738088445; bh=YmhAE2jIcsvtL1z8Vxmxfto9LgXkZ2nirzZ9sxI+eg0=; 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=piXfvQCBLHC5p8oZhgHKVndS8u6eNXJYezS9uvE+R0LUCGqvto09Vqj80SkNKE/lG MUjNw/YWjmoUWdSZqOXut2fPfYLyg/ZVkXJ2RPB2/uiKRYVE4UMBVsqz3vXrV6YO/x OfQlg8QUtQzvYQidHxW9S+cVh3Cwqr2ReTQhXbtJ4Nb6zMazI+O9jnS0O9qCDHnM00 qFm6whvgk+fMdO1lB008qNv7R/077XSsF/lgPNQHvXvWqKpNVzxGI66mk2XAOO/7e4 NGdGNlrXE2l3EwGnny1HzAOo20d3kCJirSYC6IB8o+adUWDP7SE7eWvpbo3kchAUqi CZR38OunfEs5w== Date: Sat, 25 Jan 2025 18:20:40 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87bjvusql1.fsf@protonmail.com> In-Reply-To: <868qqzuivn.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <87a5bgxnkg.fsf@protonmail.com> <865xm4xmbu.fsf@gnu.org> <87h65ow0uq.fsf@protonmail.com> <86wmekvz5q.fsf@gnu.org> <87jzajvo06.fsf@protonmail.com> <86sep7wcod.fsf@gnu.org> <87o6zvtefz.fsf@protonmail.com> <868qqzuivn.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 37fd217feeae0691a2a847ab6581fe2bc44541eb MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75754 Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@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: -1.0 (-) "Eli Zaretskii" writes: >> Date: Sat, 25 Jan 2025 09:45:19 +0000 >> From: Pip Cet >> Cc: eggert@cs.ucla.edu, michael.albinus@gmx.de, 75754@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> If there's modification involved, it's a bug which will cause apparently >> random behavior but no crashes. If there's no modification, it's a bug >> only because the code might be used with alloc.c GC. >> >> >> > Lisp_Object my_string; >> >> > char *p =3D SDATA (my_string); >> >> > /* trigger GC */ This line is not important. GC is transparent to client code like this, which doesn't violate the rules by hiding a pointer somewhere. >> >> > Faset (my_string, make_fixnum (0), make_fixnum (97)); ^^^^^ This is the important part. Faset can and does reallocate string data unpredictably. >> >> > /* code which expects p[0] to be 'a' */ >> >> >> >> If that is all the code, this is safe with feature/igc. >> > >> > You say "safe", but it sounds like we have different definitions of >> > "safe". Because later you say: >> >> I meant "won't crash, but most likely useless". >> >> >> MPS GC will never make pointers that live on the stack invalid. It's >> >> transparent to correct client programs. So, yes, if you're asking ab= out >> >> MPS GC, the sequence is safe and doesn't crash, but may surprise you = by >> >> reproducing the old string data. >> > >> > Which seems to mean your "safe" means the code will not crash, whereas >> > what I meant is the correctness of the code. Code which refers to the >> > old string data is incorrect, even if it won't crash. >> >> I believe that's true. > > The above confirms what I thought about this, thanks. The "sequence" I mentioned above included a string modification, which invalidates the SDATA pointer (sometimes). GC never does, so its inclusion in the sequence was irrelevant. >> > So my conclusion is that even with MPS, referring in code after GC to >> > an SDATA pointer taken before GC leads to incorrect code. IOW, >> > pointers to SDATA of a string cannot be relied upon to be valid >> > (i.e. pointing to the correct string) across GC, so the code must >> > re-initialize such pointer after any fragment that could GC. This was >> > the rule with the old GC, and it should continue to be the rule with >> > MPS. >> >> No. > > And this seems to contradict it. Here, you were talking ONLY about GC, the irrelevant part. GC never invalidates an SDATA pointer. Only string modification does. >> GC doesn't invalidate SDATA pointers. > > I never said anything about invalidating the SDATA pointers. So if Then they're valid. Period. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 27 04:09:16 2025 Received: (at 75754) by debbugs.gnu.org; 27 Jan 2025 09:09:16 +0000 Received: from localhost ([127.0.0.1]:59356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tcL7L-0001BA-Rw for submit@debbugs.gnu.org; Mon, 27 Jan 2025 04:09:16 -0500 Received: from mout.gmx.net ([212.227.15.15]:44663) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tcL7J-0001Ap-Bn for 75754@debbugs.gnu.org; Mon, 27 Jan 2025 04:09:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1737968944; x=1738573744; i=michael.albinus@gmx.de; bh=Pwdiu9EV0VeXtYwmxUJ7itLNh+TVvi5uzxlNfMXSPl0=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=IO632+3ZLZRZYuqbCZftyJM+x2g6/gH6kNiPniljdVFw2V3XJF/ym9FDYJCDrR60 o69KunHM809MdCktYeL8VJjVjBotBw+/f480Di5DB11AB9pVXLI407PzS5XO9KJyX FqccGHfDYO0GbSHNobAiOAXcRuDzmOfEaNul2Lk5a4xHJLd/ftdNTnij4Mp4N4s8Q cr9U9WnRE2515wX5VrMVnfPwI1YyBjC6nKU6RpnBr5pwMK4V+hjD1b8aHq/fezGBm Oo2Q4R3Rx371P33C4W+ZCp5hh1tlucd/xuhCBefQFyo1nF498UPTAMYDHkHA9CldT MsGaMsH1UbrJTMW0cw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.38.155]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1McY8d-1t45hF2rz3-00qXAT; Mon, 27 Jan 2025 10:09:04 +0100 From: Michael Albinus To: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection In-Reply-To: <874j1o1ikj.fsf@protonmail.com> (Pip Cet's message of "Fri, 24 Jan 2025 12:51:22 +0000") References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <874j1o1ikj.fsf@protonmail.com> Date: Mon, 27 Jan 2025 10:08:58 +0100 Message-ID: <874j1kk4id.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:hqbjTIj8dRTkqgU2n8d2jNpHkgsylHMFSA9g1eWqrH0X8IqOueO y8+/YGrEznzHi1ox6Ct9fGCkZvU3AMIfENurz0cjLk9rFmm+ux6DZ93ckZEnnO7wULt2SHn 2Y5jkgEioWlX6H6ENb1Doj/Jn5fUTddKHlGAtg2c4x3uNJv7hY082NFJyZkYESXWzKhpVPM ZIAIatUwzeMgd6osZBA7g== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:yIU4rGtm6HI=;Gz4CQzJ1vxS7affUsZsxXcc2+Jo tcX4WwKIrvptRYvUhTJjo1RH7dTgaxVCYZpU1ZMdbRCLu7zQuMEF0jUY5XumX3mR6SPPfqudF QqVW/YBXH95HXiZnMxvU5A9uYLCqqXay/sb63epmXuD4UN3s819GzFzGNXld9zQfI3RYC+NdA CU7ADjGQPBUmhDHjiFTRqw8xY0CXNe0QMACymKuyKfav6QhrKKu9fy0ueOlTvhsF95tsmre2H vqDjRVWdK3TxhDEAAFoOjJAqHgfCDu7YYBdeDgPk4xEX3uL+jaZvQdoTubvQr4ZAngcL9lHWq a/Ixpx6czKYXoJi23EM9I2qyiCULO549p6Wbg3GQLy4Kq4x9ycuVqZ5sDPoHpvsjT6ZQQx/4s RGDW6GOuO/YZ79EKtbWY1kWLCTMsCVSwgmwg4ER5Rs3aDV3eoffR7v6afO++N3hnywS7haUPZ 1L4o7dItvDyrVNZsU0/yyq2D+nItm47kOiameH7hByNr7V5ZdSutdEog1rqHaudlWW24pfMew sfuSwCjFvccB+Ezle5GF1cF47UrjMWIYMOF1Y3CxeAxPQryQ1tvJzW7Ah1zdGJBz5FPZrlk2o eZgE4syaRGpUNBkuioYh1ECI3rD+i4i0Y7vD8CI1AteCyPMaRjW0n/gc+gHGt7lo9m0ZgFsBe 6HZd5a6EWyQBtb7O/k9vLUv1zB7OLdU1nYuf4KXiNB8AAh+/Vr6FdgRQXfPGco9dWgusAmAeD Z+/BcG24E4e/OnTxTFPZBlVYnLl/889NV9OWDZfmYEUuX/yc6UQKCogI67VUJCjszEf7aXy76 PoJeINw5yf01L6jXYDEsAGf1ixhvDty2ei/1qhVlL/PbD1+iQdEyd7zBVLYUemZQTGaAosMJn R2mqUvedRdue6fJZzGTg++v+KKA6dGND9MIKICJlaIZTz0Y785td0kK0dpVwhxfvyTjv2saZK pKEadYdd6oBMt/TXRz2SGg2qCFIaZqZ5WI/nABKm4rceE83HvmVk/XTF89+Wj9A+Jb2WZj4Pt oFyoWCJ7DbGB1uMFWX8OcZFlVtxpQzabMr3f7kHHIMs7iNm9k5lZfo93CVh9iPu0kwWLZCEaU 6thlurYXLkJmFa71UzkW3MZ9uPBT9cV6JLI0QYeDCreCCUdxg0gSq3VJJfvHL8i2FbqjS+JGK IjYtVzXmixHUa46WJBMUlfg8QYtFOxSQT6bBhA4HB3A== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 75754 Cc: Eli Zaretskii , eggert@cs.ucla.edu, 75754@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: -1.7 (-) Pip Cet writes: Hi Pip, > Michael Albinus, could you please C-s ert-how in this message and > comment briefly if appropriate? I think adding a new defstruct may help > improve ert in at least three ways, including this one. Please indicate > whether this would be *potentially* acceptable; if it is, I'll prepare a > separate bug. If it isn't, I might have to think of something else. > (Brief proposal relevant to several issues: If we want to test GC bugs > more thoroughly, we need a way to tell ert to run them in a special way. > I proposed extending ert with an ert-how defstruct for the make > benchmark target, indicating "how" a test is to be run, and implemented > it, but I don't think I've sent the patch yet. Using this structure to > create conditions for testing for GC bugs would be possible, and it > would also be an easier way to make crash tests print a message before > they're run. No general objection from me. If you show the patch in a new bug, we'll be able to discuss. > Pip Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 03 16:02:33 2025 Received: (at 75754-done) by debbugs.gnu.org; 3 Feb 2025 21:02:33 +0000 Received: from localhost ([127.0.0.1]:41526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tf3aT-0008N5-0W for submit@debbugs.gnu.org; Mon, 03 Feb 2025 16:02:33 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:19503) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tf3aP-0008Mn-Tw for 75754-done@debbugs.gnu.org; Mon, 03 Feb 2025 16:02:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1738616542; x=1738875742; bh=U/mUprt6ySDusM+erI4jXcT/4tegtcjdLkBG/q/kZOI=; 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=Ku9BA2FPIvjLXBmse6lxQcgGEiUmA+5B3/0dP1YVqCFvPsYLMnmhvXLrm07edKdUi PlR51al5J7wI8j8NkBba4r57i+lPq238282qcv7MHdA3qYgT6Y0K/9MkdZdmOf29nh 15yXbLaRSOldL/xnFbs1rMntXekBAdha24k5aZ58C0Z8Cz4X2mLYdf4HGICpaXIyFE K7wSL2FjqfVffVhKJAvnj8IM6XhxGQvNoo1PVDPiWRcls5Fmc3Wuhmm6uNyngONE0U A66nCbbGfdLO4HM1lZwhVH+YMAr6O1DcCFdcy8dONs05uSBuw4OxLgcnGQnSyqMKQl +MOfsjtIIsfbg== Date: Mon, 03 Feb 2025 21:02:17 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <87tt9ayc7b.fsf@protonmail.com> In-Reply-To: <86plkcy6cj.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 49cc7d5d710d15a775c61e6e756c65ea07d7c2c0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754-done Cc: eggert@cs.ucla.edu, 75754-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: -1.0 (-) "Eli Zaretskii" writes: >> Date: Thu, 23 Jan 2025 23:58:41 +0000 >> From: Pip Cet >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org >> >> 1. Reload format_start and format (and end, and format0) after every >> call which might have GC'd. If you think we should do this, please >> tell me whether lisp_string_width can GC. > > It can, if called with the last argument 'true' (because > find_automatic_composition calls into Lisp). Currently, we call it > with 'false', so it cannot. > >> More importantly, assuming it doesn't, document this in every >> function in the call tree starting at lisp_string_width so we don't >> accidentally change it. >> >> 2. memcpy the format string. Two-liner, more likely to fix the bug for >> good than (1), wastes more memory (since sa_avail has been negative >> since we entered the function, this is xmalloc'd memory). >> >> 3. replace format by a ptrdiff_t and all instances of *format by >> SREF (args[0], index). Faster than 2, but many changes hurting >> readability. > > I prefer (2), I think. Assuming it indeed fixes the problem. I had to modify it slightly to copy the final NUL character (no harm done if it isn't used, but it does appear to be relied upon in a few places). Pushed now. Please test, and I'm closing this bug with the following notes for followup bugs: 1. styled_format still uses excessive amounts of stack, both because it reserves enough space to print a long double using %f (eating up all of our sa_avail space on this system), and because it reserves strlen (format)/2 argument spec slots, rather than simply counting '%' characters as we copy the string. 2. the crash tests need to be installed once we have a way of presenting "Emacs crashed" messages nicely for ERT tets. Alternatively, just wait a few weeks; people who run new test suites on old Emacs versions can expect the occasional crash. 3. If anyone wants to avoid copying the format string again (which isn't really worth it because format strings aren't usually that long), please ensure that modifying the string from Lisp callbacks in the middle of the format won't cause crashes. Thanks! Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 04 07:21:12 2025 Received: (at 75754-done) by debbugs.gnu.org; 4 Feb 2025 12:21:12 +0000 Received: from localhost ([127.0.0.1]:42997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tfHvT-0004OD-Ni for submit@debbugs.gnu.org; Tue, 04 Feb 2025 07:21:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37796) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tfHvQ-0004Nu-Ff for 75754-done@debbugs.gnu.org; Tue, 04 Feb 2025 07:21:09 -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 1tfHvK-0001qT-3N; Tue, 04 Feb 2025 07:21:02 -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=cNH/cjS1nh89kCvaj7Kpe6waUbRqEkrvj6husMwjnwE=; b=qKAMOMIeezt+ 1xMmkBiQf78Klb8jQ3OYQQWeLPIwXVjtu/Knt9Yf3hi9QelQU7eACRaXy+mbC3iG4BMTNlvalGBqm hp9AUa3PTFVZvfxaejS1jNlpTSYS2JaVs0cP5CMSh7elN9asD9jIH97yRHzDJgHkgAgFZaayxuhxD hOO8SJ3Ah3L2gOFMsSipOV97hZI1/WQggWYtGJRnKZOmoSzu1d9zNRJeMl+GhEi86XWb+55H91Udv mw8wakbK0AzN4kVhcDeKPZW0HttvssHTO8zeXMA0t0d5Hlt3b6v5ys6yxLEG0ZMhbBm+TmiBwbDJC iAEjvjdgu6BTHw2cJajqiQ==; Date: Tue, 04 Feb 2025 14:21:00 +0200 Message-Id: <86a5b1c34j.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87tt9ayc7b.fsf@protonmail.com> (message from Pip Cet on Mon, 03 Feb 2025 21:02:17 +0000) Subject: Re: bug#75754: styled_format stack usage/GC protection References: <87sepbdudr.fsf@protonmail.com> <86ikq63krq.fsf@gnu.org> <878qr2ab9v.fsf@protonmail.com> <86bjvy2i9t.fsf@gnu.org> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <87tt9ayc7b.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75754-done Cc: eggert@cs.ucla.edu, 75754-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: -3.3 (---) > Date: Mon, 03 Feb 2025 21:02:17 +0000 > From: Pip Cet > Cc: eggert@cs.ucla.edu, 75754-done@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> Date: Thu, 23 Jan 2025 23:58:41 +0000 > >> From: Pip Cet > >> Cc: eggert@cs.ucla.edu, 75754@debbugs.gnu.org > >> > >> 1. Reload format_start and format (and end, and format0) after every > >> call which might have GC'd. If you think we should do this, please > >> tell me whether lisp_string_width can GC. > > > > It can, if called with the last argument 'true' (because > > find_automatic_composition calls into Lisp). Currently, we call it > > with 'false', so it cannot. > > > >> More importantly, assuming it doesn't, document this in every > >> function in the call tree starting at lisp_string_width so we don't > >> accidentally change it. > >> > >> 2. memcpy the format string. Two-liner, more likely to fix the bug for > >> good than (1), wastes more memory (since sa_avail has been negative > >> since we entered the function, this is xmalloc'd memory). > >> > >> 3. replace format by a ptrdiff_t and all instances of *format by > >> SREF (args[0], index). Faster than 2, but many changes hurting > >> readability. > > > > I prefer (2), I think. Assuming it indeed fixes the problem. > > I had to modify it slightly to copy the final NUL character (no harm > done if it isn't used, but it does appear to be relied upon in a few > places). > > Pushed now. Please test Thanks, the test I wrote now passes, so I've installed it. > 2. the crash tests need to be installed once we have a way of presenting > "Emacs crashed" messages nicely for ERT tets. Alternatively, just wait > a few weeks; people who run new test suites on old Emacs versions can > expect the occasional crash. Does this mean you didn't want me to install the test? It doesn't crash. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 04 07:31:38 2025 Received: (at 75754-done) by debbugs.gnu.org; 4 Feb 2025 12:31:38 +0000 Received: from localhost ([127.0.0.1]:43023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tfI5a-0007uz-4r for submit@debbugs.gnu.org; Tue, 04 Feb 2025 07:31:38 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:31709) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tfI5X-0007ui-Dg for 75754-done@debbugs.gnu.org; Tue, 04 Feb 2025 07:31:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1738672288; x=1738931488; bh=uxkvbst6L20dXc/tUWre2FgZN6F7QLA4oO0IjUYFbNA=; 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=kIltAbVJQgPbRCFz1LR6edZXoja/yPHN4eYq/1MNongqZpyAOJfDk3OJ8LtissQtu /+8WPdcNAy6+yrLIdVswieP5gdgwT4pn+55/Rbf8RE0RnjrQEbnR62sUlyk6aQDPgI SE8sGvkYuR0PUlv/AiC9uR1/af8tyDbXTyIQ2utZ0KkrB6KrxVUDljpQdU/GbStuqb INTI3AsNCtqSKLSIiHZmHRUiAYytbsS3kWAangdloClavOiCYgBlDuX+5Vs9Iw3wIg E182pSxHXMFqg/E97zGog3OEpkvZxb4Z1sUw7+pj8KyCfZk/KpYRQJ/0gJuS1FcXN2 95Gy9pP2fKTRA== Date: Tue, 04 Feb 2025 12:31:21 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75754: styled_format stack usage/GC protection Message-ID: <878qqlx56w.fsf@protonmail.com> In-Reply-To: <86a5b1c34j.fsf@gnu.org> References: <87sepbdudr.fsf@protonmail.com> <26df46b7-6f51-497f-9580-e9763118d6df@cs.ucla.edu> <86o6zxzahc.fsf@gnu.org> <87jzal2uni.fsf@protonmail.com> <864j1pz2xs.fsf@gnu.org> <87ed0t13ru.fsf@protonmail.com> <86plkcy6cj.fsf@gnu.org> <87tt9ayc7b.fsf@protonmail.com> <86a5b1c34j.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5c803ecf0ffd3cad44f4a33399978e180eae710f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75754-done Cc: eggert@cs.ucla.edu, 75754-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: -1.0 (-) "Eli Zaretskii" writes: >> 2. the crash tests need to be installed once we have a way of presenting >> "Emacs crashed" messages nicely for ERT tets. Alternatively, just wait >> a few weeks; people who run new test suites on old Emacs versions can >> expect the occasional crash. > > Does this mean you didn't want me to install the test? It doesn't > crash. I was worried that people might run the current test suite with older versions of Emacs to get a which-test-was-fixed-when dataset, and that crashes may get in the way. But I don't really see a problem with that, to be honest, so no continued objections from me! Thanks for installing this! Pip From unknown Fri Aug 15 12:50:54 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 05 Mar 2025 12:24:15 +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