GNU bug report logs - #67883
29.1.90; Native compiler hangs when compiling code with circular objects

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 67883 in the body.
You can then email your comments to 67883 AT debbugs.gnu.org in the normal way.

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

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

From: hokomo <hokomo <at> disroot.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.1.90; Native compiler hangs when compiling code with circular
 objects
Date: Mon, 18 Dec 2023 18:22:41 +0100

Hello,

The Emacs Lisp native compiler goes into an infinite loop when 
compiling code that contains circular objects.

For example, put the following into a file and use M-x 
emacs-lisp-native-compile; it should hang:

 (defun test1 ()
   '#1=(1 2 3 . #1#))

It seems like this only happens for certain top-level forms, such 
as `defun' (which may be expected behavior, due to the way the 
file compiler processes top-level forms). For example, this 
doesn't hang:

 (lambda ()
   '#1=(1 2 3 . #1#))

Here's a more interesting example, which is how I stumbled upon 
this issue in the first place:

 (defun cycle-pure (list)
   (declare (pure t) (side-effect-free t))
   (let ((newlist (append list ())))
     (nconc newlist newlist)))

 (defun test2 ()
   (cycle-pure '(1 2 3)))

(The definition of `cycle-pure' is copied from the `-cycle' 
function from the dash.el package.)

If `cycle-pure' is not yet defined when compiling, the compiler 
doesn't hang.

However, if `cycle-pure' is defined (e.g. via M-x eval-defun), the 
compiler hangs. This is weird because, unlike `test1' above, 
`test2' doesn't contain a circular list itself; it only builds it 
at run-time.

In contrast, this example doesn't hang, regardless of whether 
`cycle' is defined or not (note the removed declarations):

 (defun cycle (list)
   (let ((newlist (append list ())))
     (nconc newlist newlist)))

 (defun test3 ()
   (cycle '(1 2 3)))

My conjecture is that the `pure' and `side-effect-free' 
declarations within `cycle-pure' (which I assume are picked up 
only once the function definition is loaded) allow the compiler to 
do some constant folding when it sees the expression `(cycle-pure 
'(1 2 3))'. This results in the compiler manipulating a circular 
list at compile-time, just like in `test1', and leads to a hang.

Kind regards,
hokomo

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: hokomo via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 67883 <at> debbugs.gnu.org, hokomo <hokomo <at> disroot.org>
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Tue, 19 Dec 2023 07:48:50 -0500

hokomo via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Hello,
>
> The Emacs Lisp native compiler goes into an infinite loop when
> compiling code that contains circular objects.
>
> For example, put the following into a file and use M-x
> emacs-lisp-native-compile; it should hang:
>
>  (defun test1 ()
>    '#1=(1 2 3 . #1#))
>
> It seems like this only happens for certain top-level forms, such as
> `defun' (which may be expected behavior, due to the way the file
> compiler processes top-level forms). For example, this doesn't hang:
>
>  (lambda ()
>    '#1=(1 2 3 . #1#))
>
> Here's a more interesting example, which is how I stumbled upon this
> issue in the first place:
>
>  (defun cycle-pure (list)
>    (declare (pure t) (side-effect-free t))
>    (let ((newlist (append list ())))
>      (nconc newlist newlist)))
>
>  (defun test2 ()
>    (cycle-pure '(1 2 3)))
>
> (The definition of `cycle-pure' is copied from the `-cycle' function
> from the dash.el package.)
>
> If `cycle-pure' is not yet defined when compiling, the compiler
> doesn't hang.
>
> However, if `cycle-pure' is defined (e.g. via M-x eval-defun), the
> compiler hangs. This is weird because, unlike `test1' above, `test2'
> doesn't contain a circular list itself; it only builds it at run-time.
>
> In contrast, this example doesn't hang, regardless of whether `cycle'
> is defined or not (note the removed declarations):
>
>  (defun cycle (list)
>    (let ((newlist (append list ())))
>      (nconc newlist newlist)))
>
>  (defun test3 ()
>    (cycle '(1 2 3)))
>
> My conjecture is that the `pure' and `side-effect-free' declarations
> within `cycle-pure' (which I assume are picked up only once the
> function definition is loaded) allow the compiler to do some constant
> folding when it sees the expression `(cycle-pure '(1 2 3))'. This
> results in the compiler manipulating a circular list at compile-time,
> just like in `test1', and leads to a hang.
>
> Kind regards,
> hokomo

I'm pretty sure I've investigated this in the past.  IIRC this is due
some cl- function hanging on a circular list.  Can't find the bug number
ATM.

  Andrea

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: 67883 <at> debbugs.gnu.org
Cc: hokomo <at> disroot.org
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Tue, 19 Dec 2023 08:29:44 -0500

Andrea Corallo <acorallo <at> gnu.org> writes:

> hokomo via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Hello,
>>
>> The Emacs Lisp native compiler goes into an infinite loop when
>> compiling code that contains circular objects.
>>
>> For example, put the following into a file and use M-x
>> emacs-lisp-native-compile; it should hang:
>>
>>  (defun test1 ()
>>    '#1=(1 2 3 . #1#))
>>
>> It seems like this only happens for certain top-level forms, such as
>> `defun' (which may be expected behavior, due to the way the file
>> compiler processes top-level forms). For example, this doesn't hang:
>>
>>  (lambda ()
>>    '#1=(1 2 3 . #1#))
>>
>> Here's a more interesting example, which is how I stumbled upon this
>> issue in the first place:
>>
>>  (defun cycle-pure (list)
>>    (declare (pure t) (side-effect-free t))
>>    (let ((newlist (append list ())))
>>      (nconc newlist newlist)))
>>
>>  (defun test2 ()
>>    (cycle-pure '(1 2 3)))
>>
>> (The definition of `cycle-pure' is copied from the `-cycle' function
>> from the dash.el package.)
>>
>> If `cycle-pure' is not yet defined when compiling, the compiler
>> doesn't hang.
>>
>> However, if `cycle-pure' is defined (e.g. via M-x eval-defun), the
>> compiler hangs. This is weird because, unlike `test1' above, `test2'
>> doesn't contain a circular list itself; it only builds it at run-time.
>>
>> In contrast, this example doesn't hang, regardless of whether `cycle'
>> is defined or not (note the removed declarations):
>>
>>  (defun cycle (list)
>>    (let ((newlist (append list ())))
>>      (nconc newlist newlist)))
>>
>>  (defun test3 ()
>>    (cycle '(1 2 3)))
>>
>> My conjecture is that the `pure' and `side-effect-free' declarations
>> within `cycle-pure' (which I assume are picked up only once the
>> function definition is loaded) allow the compiler to do some constant
>> folding when it sees the expression `(cycle-pure '(1 2 3))'. This
>> results in the compiler manipulating a circular list at compile-time,
>> just like in `test1', and leads to a hang.
>>
>> Kind regards,
>> hokomo
>
> I'm pretty sure I've investigated this in the past.  IIRC this is due
> some cl- function hanging on a circular list.  Can't find the bug number
> ATM.
>
>   Andrea

Okay I believe this most likely is a duplicate of bug#57957.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>, 67883 <at> debbugs.gnu.org
Cc: hokomo <at> disroot.org
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Sun, 24 Dec 2023 11:41:12 -0800

Andrea Corallo <acorallo <at> gnu.org> writes:

> Okay I believe this most likely is a duplicate of bug#57957.

Should the bugs be merged?

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 67883 <at> debbugs.gnu.org, hokomo <at> disroot.org
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Tue, 26 Dec 2023 03:23:07 -0500

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Okay I believe this most likely is a duplicate of bug#57957.
>
> Should the bugs be merged?

Hi Stefan,

yes I think so.

  Andrea

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: 67883 <at> debbugs.gnu.org, hokomo <at> disroot.org
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Tue, 26 Dec 2023 09:36:16 -0600

forcemerge 57957 67883
thanks

Andrea Corallo <acorallo <at> gnu.org> writes:

> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Andrea Corallo <acorallo <at> gnu.org> writes:
>>
>>> Okay I believe this most likely is a duplicate of bug#57957.
>>
>> Should the bugs be merged?
>
> Hi Stefan,
>
> yes I think so.
>
>   Andrea

Done.

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

From: hokomo <hokomo <at> disroot.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 67883 <at> debbugs.gnu.org, Andrea Corallo <acorallo <at> gnu.org>
Subject: Re: bug#67883: 29.1.90; Native compiler hangs when compiling code
 with circular objects
Date: Wed, 27 Dec 2023 19:48:23 +0100

Merging the two indeed seems appropriate.

FWIW, I've read the other thread [1] and agree with Stefan's view 
that circular structures should be handled correctly by the 
compiler. I believe the example with `cycle-pure' shows that this 
is both useful and necessary, since circular structures can appear 
even without being directly present in the source code as 
literals, e.g. after compiler optimizations (which seems to be the 
case here, although I haven't confirmed it 100%).

- [1] <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57957>

Kind regards,
hokomo

Previous Next

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