GNU bug report logs - #61504
29.0.60; executing byte-code from previous build causes SIGSEGV crash

Previous Next

Full log

Message #14 received at 61504 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Istvan Marko <mi-ebugs <at> kismala.com>, Eli Zaretskii <eliz <at> gnu.org>,
 61504 <at> debbugs.gnu.org
Subject: Re: bug#61504: 29.0.60; executing byte-code from previous build
 causes SIGSEGV crash
Date: Tue, 14 Feb 2023 10:22:05 -0500

> Eli, what do you think of the attached patch?  It restores the 'unbind 1' at
> the end of save-restriction, and puts the two data elements into a cons
> instead of pushing them separately.  (Of course this passes make and make
> check, with and without native compilation.)

Looks right to me.
Some comments below.


        Stefan


> @@ -940,10 +940,9 @@ #define DEFINE(name, value) [name] = &&insn_ ## name,
>  	  }
>  
>  	CASE (Bsave_restriction):
> -	  record_unwind_protect (save_restriction_restore,
> -				 save_restriction_save ());
> -	  record_unwind_protect (narrowing_locks_restore,
> -				 narrowing_locks_save ());
> +	  record_unwind_protect (save_restriction_and_narrowing_locks_restore,
> +				 Fcons (save_restriction_save (),
> +					narrowing_locks_save ()));
>  	  NEXT;

Shouldn't the value returned by `save_restriction_save` include the
narrowing locks already?

IOW rather than changing this `bytecode.c` code, the locks handling
should be "hidden" inside `save_restriction_restore` and
`save_restriction_save`, don't you think?


        Stefan

Previous Next

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