GNU bug report logs - #56794
Segmentation fault in purecopy while dumping - stack overflow attempting to copy cyclic Lisp value

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 56794 in the body.
You can then email your comments to 56794 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: Lynn Winebarger <owinebar <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Segmentation fault in purecopy while dumping - stack overflow
 attempting to copy cyclic Lisp value
Date: Wed, 27 Jul 2022 10:07:35 -0400

[Message part 1 (text/plain, inline)]

I apologize for not being able to include significant details of the build,
as this is happening on a sandboxed system in a proprietary context.
I've been attempting to dump emacs built from the 28.1 tarball with a large
number of core libraries preloaded.  I have observed segmentation faults
when attempting to dump with native-compilation enabled and with
native-compilation disabled.  However, it only happened with one file
(nxml/rng-pttrn.el) while dumping several hundred core libraries with
native compilation.  With native compilation disabled, the problem has
appeared with both auth-source.el and emacs-lisp/eieio-core.el, the latter
preventing me from proceeding much further in the dump process.  Note these
were both dumped successfully with native-compilation enabled.
I used gdb to look at the backtrace after the segmentation fault while
loading auth-source.el, and the stack was in a tight recursive loop in
purecopy:

for (i = 0; i < size; i++)

vec->contents[i] = purecopy (vec->contents[i]);

In this case the index I alternated between two values in each pair of
stack frames: 0 and 10.
I'm not familiar enough with the layout of lisp objects to recognize the
pseudo vector type on site, but it's probably a byte-vector with a
recursive call - the constants vector in slot 0, and the recursive binding
in slot 10 of the constants vector.  Plus, the fact that this started
happening more frequently with byte-compilation only is suspicious in
itself.
Since I'm restricted to using official release tarballs with only local
modifications, I'd welcome any hints on any "quick fix" to the problem
aside from the long-term solution of just eliminating purecopy altogether
(unless that can be done with a de minimis change to the code).

Lynn

[Message part 2 (text/html, inline)]

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

From: Lynn Winebarger <owinebar <at> gmail.com>
To: 56794 <at> debbugs.gnu.org
Subject: Recompiled with proper debugging flags and found the offending object
Date: Wed, 27 Jul 2022 19:06:28 -0400

The cyclic object is a record with the type field (index 0) set to the
eieio-default-class, which has the cyclic record at index 10.
I don't know if this is a bug in itself or not.  I put a check for
this case in purecopy (splitting off the RECORDP case), printing a
message whenever a record with a non-symbol entry 0 is encountered.
So far it's only this one.
Also, it seems weird this was not an issue for the build with native
compilation enabled.

Lynn

Message #13 received at 56794-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: 56794-done <at> debbugs.gnu.org
Subject: Re: bug#56794: Segmentation fault in purecopy while dumping - stack
 overflow attempting to copy cyclic Lisp value
Date: Wed, 12 Feb 2025 06:02:28 -0800

Lynn Winebarger <owinebar <at> gmail.com> writes:

> I apologize for not being able to include significant details of the build, as this is happening on a
> sandboxed system in a proprietary context.
> I've been attempting to dump emacs built from the 28.1 tarball with a large number of core libraries
> preloaded.  I have observed segmentation faults when attempting to dump with native-compilation
> enabled and with native-compilation disabled.  However, it only happened with one file
> (nxml/rng-pttrn.el) while dumping several hundred core libraries with native compilation.  With native
> compilation disabled, the problem has appeared with both auth-source.el and
> emacs-lisp/eieio-core.el, the latter preventing me from proceeding much further in the dump process.
>  Note these were both dumped successfully with native-compilation enabled.
> I used gdb to look at the backtrace after the segmentation fault while loading auth-source.el, and the
> stack was in a tight recursive loop in purecopy:
>
>  for (i = 0; i < size; i++)
>
>  vec->contents[i] = purecopy (vec->contents[i]);
>
> In this case the index I alternated between two values in each pair of stack frames: 0 and 10.
> I'm not familiar enough with the layout of lisp objects to recognize the pseudo vector type on site, but
> it's probably a byte-vector with a recursive call - the constants vector in slot 0, and the recursive
> binding in slot 10 of the constants vector.  Plus, the fact that this started happening more frequently
> with byte-compilation only is suspicious in itself.
> Since I'm restricted to using official release tarballs with only local modifications, I'd welcome any
> hints on any "quick fix" to the problem aside from the long-term solution of just eliminating purecopy
> altogether (unless that can be done with a de minimis change to the code).

With the removal of purespace on master, `purecopy' is now an alias for
`identity', so I don't think there's anything more to do here.  Thanks
for reporting it, nevertheless.

I'm therefore closing this bug report.

Previous Next

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