GNU bug report logs - #76546
30.1; Native compilation is corrupting lambdas/closures stored in variables after some time

Previous Next

To reply to this bug, email your comments to 76546 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Christian Johansson <christian <at> cvj.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; Native compilation is corrupting lambdas/closures stored in
 variables after some time
Date: Tue, 25 Feb 2025 11:27:58 +0100

Hello!

There is something fishy going on, but it is a very slippery bug, I have 
trouble reproducing it but it started to happen when native compilation 
was introduced and it has significantly gotten worse with Emacs 30, I 
never happened before native-compilation was introduced.

Maybe you can give me some tips in building a reproducible test case? I 
will try to explain what happens. So prior to Emacs 30 there was only 
one bug I stumbled upon:

1. When a lambda is stored in a variable in a lexical scoped file it 
stores a closure. After some time when native compilation has done its 
magic on the variable you will get an error when you try to output it 
like this:
(format "%S" my-native-compiled-variable) and Emacs crashes.

This happened every time my parser-generator library ran for a long time 
and then tried to output a parser file. The only solution to this was to 
not byte-compile the file that contained the lambdas that was later 
supposed to be printed to a file, this solution worked but it was a 
workaround due to this bug.


2. After Emacs 30 it seems to corrupt strings with escape sequences 
inside lambdas inside variables, like this:

(setq my-lambda (lambda() (looking-at "<\\?=")))

After native-compilation has performed its magic on the variable the 
function body will become corrupted and it will become a invalid 
function body. This happens now to my major my phps-mode, I have 
reproduced the error on two machines with Emacs 30 and it has never 
occurred before Emacs 30 and there has been no recent changes to the 
plugin. If I just eval the function files anew the problem disappears so 
it only happens in compiled files. It however does not happen in 
byte-compiled files, only in native compiled files.


Kind regards
Christian

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christian Johansson <christian <at> cvj.se>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 76546 <at> debbugs.gnu.org
Subject: Re: bug#76546: 30.1;
 Native compilation is corrupting lambdas/closures stored in variables
 after some time
Date: Wed, 26 Feb 2025 14:43:30 +0200

> Date: Tue, 25 Feb 2025 11:27:58 +0100
> From: Christian Johansson <christian <at> cvj.se>
> 
> There is something fishy going on, but it is a very slippery bug, I have 
> trouble reproducing it but it started to happen when native compilation 
> was introduced and it has significantly gotten worse with Emacs 30, I 
> never happened before native-compilation was introduced.
> 
> Maybe you can give me some tips in building a reproducible test case? I 
> will try to explain what happens. So prior to Emacs 30 there was only 
> one bug I stumbled upon:
> 
> 1. When a lambda is stored in a variable in a lexical scoped file it 
> stores a closure. After some time when native compilation has done its 
> magic on the variable you will get an error when you try to output it 
> like this:
> (format "%S" my-native-compiled-variable) and Emacs crashes.
> 
> This happened every time my parser-generator library ran for a long time 
> and then tried to output a parser file. The only solution to this was to 
> not byte-compile the file that contained the lambdas that was later 
> supposed to be printed to a file, this solution worked but it was a 
> workaround due to this bug.
> 
> 
> 2. After Emacs 30 it seems to corrupt strings with escape sequences 
> inside lambdas inside variables, like this:
> 
> (setq my-lambda (lambda() (looking-at "<\\?=")))
> 
> After native-compilation has performed its magic on the variable the 
> function body will become corrupted and it will become a invalid 
> function body. This happens now to my major my phps-mode, I have 
> reproduced the error on two machines with Emacs 30 and it has never 
> occurred before Emacs 30 and there has been no recent changes to the 
> plugin. If I just eval the function files anew the problem disappears so 
> it only happens in compiled files. It however does not happen in 
> byte-compiled files, only in native compiled files.

Andrea, any comments or suggestions?

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

From: Christian Johansson <christian <at> cvj.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76546 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>
Subject: Re: bug#76546: 30.1;
 Native compilation is corrupting lambdas/closures stored in variables
 after some time
Date: Wed, 26 Feb 2025 21:55:28 +0100

Today the error disappeared on both machines without any changes in code, it makes no sense really but if I could trigger native compilation I could do some testing back and forth. It can be a issue with the garbage collection mechanism also, the things could be dependent on each other as well. Maybe only native compiled + byte compiled + garbage collected variables get corrupted sometimes?

Non reproducible bugs that only happen after a significant period of time.. variable data gets corrupted, that is at least true

Kind Regards
Christian

> On 26 Feb 2025, at 14:03, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> 
>> 
>> Date: Tue, 25 Feb 2025 11:27:58 +0100
>> From: Christian Johansson <christian <at> cvj.se>
>> 
>> There is something fishy going on, but it is a very slippery bug, I have
>> trouble reproducing it but it started to happen when native compilation
>> was introduced and it has significantly gotten worse with Emacs 30, I
>> never happened before native-compilation was introduced.
>> 
>> Maybe you can give me some tips in building a reproducible test case? I
>> will try to explain what happens. So prior to Emacs 30 there was only
>> one bug I stumbled upon:
>> 
>> 1. When a lambda is stored in a variable in a lexical scoped file it
>> stores a closure. After some time when native compilation has done its
>> magic on the variable you will get an error when you try to output it
>> like this:
>> (format "%S" my-native-compiled-variable) and Emacs crashes.
>> 
>> This happened every time my parser-generator library ran for a long time
>> and then tried to output a parser file. The only solution to this was to
>> not byte-compile the file that contained the lambdas that was later
>> supposed to be printed to a file, this solution worked but it was a
>> workaround due to this bug.
>> 
>> 
>> 2. After Emacs 30 it seems to corrupt strings with escape sequences
>> inside lambdas inside variables, like this:
>> 
>> (setq my-lambda (lambda() (looking-at "<\\?=")))
>> 
>> After native-compilation has performed its magic on the variable the
>> function body will become corrupted and it will become a invalid
>> function body. This happens now to my major my phps-mode, I have
>> reproduced the error on two machines with Emacs 30 and it has never
>> occurred before Emacs 30 and there has been no recent changes to the
>> plugin. If I just eval the function files anew the problem disappears so
>> it only happens in compiled files. It however does not happen in
>> byte-compiled files, only in native compiled files.
> 
> Andrea, any comments or suggestions?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christian Johansson <christian <at> cvj.se>
Cc: 76546 <at> debbugs.gnu.org, acorallo <at> gnu.org
Subject: Re: bug#76546: 30.1;
 Native compilation is corrupting lambdas/closures stored in variables
 after some time
Date: Thu, 27 Feb 2025 10:02:41 +0200

> From: Christian Johansson <christian <at> cvj.se>
> Date: Wed, 26 Feb 2025 21:55:28 +0100
> Cc: Andrea Corallo <acorallo <at> gnu.org>, 76546 <at> debbugs.gnu.org
> 
> Today the error disappeared on both machines without any changes in code, it makes no sense really but if I could trigger native compilation I could do some testing back and forth. It can be a issue with the garbage collection mechanism also, the things could be dependent on each other as well. Maybe only native compiled + byte compiled + garbage collected variables get corrupted sometimes?

If you need a way to trigger native compilation, then removing the
corresponding .eln file(s) should do it.

Previous Next

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