[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61504: 29.0.60; executing byte-code from previous build causes SIGSE
From: |
Stefan Monnier |
Subject: |
bug#61504: 29.0.60; executing byte-code from previous build causes SIGSEGV crash |
Date: |
Tue, 14 Feb 2023 10:22:05 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
> 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
- bug#61504: 29.0.60; executing byte-code from previous build causes SIGSEGV crash, (continued)
bug#61504: 29.0.60; executing byte-code from previous build causes SIGSEGV crash,
Stefan Monnier <=
bug#61504: 29.0.60; executing byte-code from previous build causes SIGSEGV crash, Istvan Marko, 2023/02/14