GNU bug report logs - #79483
Segmentation fault: set-car! in compiled code

Previous Next

To reply to this bug, email your comments to 79483 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: Владимир ВНИИАЭС
 <var-vniiaes <at> mail.ru>
To: bug-guile <at> gnu.org
Subject: Segmentation fault: set-car! in compiled code
Date: Mon, 22 Sep 2025 00:50:57 +0300

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

Hello,
 
Execution of   (set-car! '(0) 1)   *in compiled code*  leads to segfault:
 
amaya <at> AM4:~$ guile-3.0 --version
guile (GNU Guile) 3.0.10
Packaged by Debian (3.0.10+really3.0.10-4)
Copyright (C) 2024 Free Software Foundation, Inc.
 
License LGPLv3+: GNU LGPL 3 or later <http://gnu.org/licenses/lgpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
 
amaya <at> AM4:~$ echo "(set-car! '(0) 1)" > /tmp/t.scm && guile /tmp/t.scm
;;; note: source file /tmp/t.scm
;;;       newer than compiled /home/amaya/.cache/guile/ccache/3.0-LE-8-4.7/tmp/t.scm.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /tmp/t.scm
;;; compiled /home/amaya/.cache/guile/ccache/3.0-LE-8-4.7/tmp/t.scm.go
Segmentation fault (core dumped)
     
 
 
 

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

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

From: <tomas <at> tuxteam.de>
To: Владимир ВНИИАЭС
 <var-vniiaes <at> mail.ru>
Cc: 79483 <at> debbugs.gnu.org
Subject: Re: bug#79483: Segmentation fault: set-car! in compiled code
Date: Mon, 22 Sep 2025 06:35:18 +0200

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

On Mon, Sep 22, 2025 at 12:50:57AM +0300, var-vniiaes--- via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote:
> 
> Hello,
>  
> Execution of   (set-car! '(0) 1)   *in compiled code*  leads to segfault:

First of all: you shouldn't be doing that :)

You are mutating a constant. I don't know what the Scheme specification says
to it (if at all).

The other question is whether Guile should/could catch that and signal an
error instead.

Cheers
-- 
t

[signature.asc (application/pgp-signature, inline)]

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

From: Tomas Volf <~@wolfsden.cz>
To: <tomas <at> tuxteam.de>
Cc: Владимир ВНИИАЭС
 <var-vniiaes <at> mail.ru>, 79483 <at> debbugs.gnu.org
Subject: Re: bug#79483: Segmentation fault: set-car! in compiled code
Date: Mon, 22 Sep 2025 21:27:54 +0200

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

<tomas <at> tuxteam.de> writes:

> On Mon, Sep 22, 2025 at 12:50:57AM +0300, var-vniiaes--- via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote:
>> 
>> Hello,
>>  
>> Execution of   (set-car! '(0) 1)   *in compiled code*  leads to segfault:
>
> First of all: you shouldn't be doing that :)
>
> You are mutating a constant. I don't know what the Scheme specification says
> to it (if at all).

--8<---------------cut here---------------start------------->8---
As noted in section 3.4, it is an error to attempt to alter
a constant (i.e. the value of a literal expression) using a
mutation procedure like set-car! or string-set!
--8<---------------cut here---------------end--------------->8---

> The other question is whether Guile should/could catch that and signal an
> error instead.

I believe it should not.  Memory-safe languages (and, Guile is supposed
to be one) should never segfault but instead terminate with a sensible
error.  I realize that 1.3.2 allows to "fail catastrophically", which
segfault probably qualifies as, but I believe we should do better.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

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

From: tomas <at> tuxteam.de
To: Tomas Volf <~@wolfsden.cz>
Cc: Владимир ВНИИАЭС
 <var-vniiaes <at> mail.ru>, 79483 <at> debbugs.gnu.org
Subject: Re: bug#79483: Segmentation fault: set-car! in compiled code
Date: Tue, 23 Sep 2025 06:22:45 +0200

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

On Mon, Sep 22, 2025 at 09:27:54PM +0200, Tomas Volf wrote:
> <tomas <at> tuxteam.de> writes:
> 
> > On Mon, Sep 22, 2025 at 12:50:57AM +0300, var-vniiaes--- via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote:
> >> 
> >> Hello,
> >>  
> >> Execution of   (set-car! '(0) 1)   *in compiled code*  leads to segfault:
> >
> > First of all: you shouldn't be doing that :)
> >
> > You are mutating a constant. I don't know what the Scheme specification says
> > to it (if at all).
> 
> --8<---------------cut here---------------start------------->8---
> As noted in section 3.4, it is an error to attempt to alter
> a constant (i.e. the value of a literal expression) using a
> mutation procedure like set-car! or string-set!
> --8<---------------cut here---------------end--------------->8---
> 
> > The other question is whether Guile should/could catch that and signal an
> > error instead.
> 
> I believe it should not.

This is ambiguous, but from the context below I think you mean Guile
should catch it. I agree :-)

> Memory-safe languages (and, Guile is supposed
> to be one) should never segfault but instead terminate with a sensible
> error.  I realize that 1.3.2 allows to "fail catastrophically", which
> segfault probably qualifies as, but I believe we should do better.

Definitely -- the question is whether Guile wants to rely on the
OS/runtime to catch an out-of-bounds access (or more probably here
an access to a region marked read-onls) or catch it itself.

Cheers
-- 
tomás

[signature.asc (application/pgp-signature, inline)]

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

From: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
To: tomas <at> tuxteam.de, ~@wolfsden.cz, var-vniiaes <at> mail.ru
Cc: bug-guile <at> gnu.org
Subject: bug#79483: Segmentation fault: set-car! in compiled code
Date: Tue, 21 Oct 2025 02:04:54 -0400

On Tue, Sep 23, 2025 at 06:22:45AM +0200, tomas wrote:
> On Mon, Sep 22, 2025 at 09:27:54PM +0200, Tomas Volf wrote:
> > <tomas <at> tuxteam.de> writes:
> >
> > > On Mon, Sep 22, 2025 at 12:50:57AM +0300, var-vniiaes--- via Bug reports
> > > for GUILE, GNU's Ubiquitous Extension Language wrote:
> > >>
> > >> Hello,
> > >>
> > >> Execution of   (set-car! '(0) 1)   *in compiled code*  leads to segfault:
> > >
> > > First of all: you shouldn't be doing that :)
> > >
> > > You are mutating a constant. I don't know what the Scheme specification says
> > > to it (if at all).
> >
> > --8<---------------cut here---------------start------------->8---
> > As noted in section 3.4, it is an error to attempt to alter
> > a constant (i.e. the value of a literal expression) using a
> > mutation procedure like set-car! or string-set!
> > --8<---------------cut here---------------end--------------->8---
> >
> > > The other question is whether Guile should/could catch that and signal an
> > > error instead.
> >
> > I believe it should not.
>
> This is ambiguous, but from the context below I think you mean Guile
> should catch it. I agree :-)
>
> > Memory-safe languages (and, Guile is supposed
> > to be one) should never segfault but instead terminate with a sensible
> > error.  I realize that 1.3.2 allows to "fail catastrophically", which
> > segfault probably qualifies as, but I believe we should do better.
>
> Definitely -- the question is whether Guile wants to rely on the
> OS/runtime to catch an out-of-bounds access (or more probably here
> an access to a region marked read-onls) or catch it itself.

Another way to trigger it is to run:

    (use-modules (system vm disassembler))
    (disassemble-image (compile '(set-car! (0) 1) #:to 'bytecode))

The above makes it seem like it's not a permissions error but an
out-of-bounds error, and indeed in a gdb session just after the
segfault I see:

    (gdb) l
    1928        {
    1929          uint8_t obj, idx, val;
    1930
    1931          UNPACK_8_8_8 (op, obj, idx, val);
    1932
    1933          SCM_SET_CELL_OBJECT (SP_REF (obj), idx, SP_REF (val));
    1934
    1935          NEXT (1);
    1936        }
    (gdb) p SP_REF(obj)
    Cannot access memory at address 0x7ffff7e09eb8
    (gdb) info proc mappings
    .
    .
    .
    0x7ffff7e07000     0x7ffff7e09000     0x2000        0x0  rw-p
    0x7ffff7e0a000     0x7ffff7e2a000    0x20000        0x0  rw-p

As you can see the memory address 0x7ffff7e09eb8 is not part of the
mappings of the process as it lies between the above two listed
mappings.

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

From: tomas <at> tuxteam.de
To: Nikolaos Chatzikonstantinou <nchatz314 <at> gmail.com>
Cc: bug-guile <at> gnu.org, ~@wolfsden.cz, var-vniiaes <at> mail.ru
Subject: Re: bug#79483: Segmentation fault: set-car! in compiled code
Date: Tue, 21 Oct 2025 09:04:36 +0200

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

On Tue, Oct 21, 2025 at 02:04:54AM -0400, Nikolaos Chatzikonstantinou wrote:

[...]

> Another way to trigger it is to run:
> 
>     (use-modules (system vm disassembler))
>     (disassemble-image (compile '(set-car! (0) 1) #:to 'bytecode))
> 
> The above makes it seem like it's not a permissions error but an
> out-of-bounds error, and indeed in a gdb session just after the
> segfault I see:
> 
>     (gdb) l
>     1928        {
>     1929          uint8_t obj, idx, val;
>     1930
>     1931          UNPACK_8_8_8 (op, obj, idx, val);
>     1932
>     1933          SCM_SET_CELL_OBJECT (SP_REF (obj), idx, SP_REF (val));
>     1934
>     1935          NEXT (1);
>     1936        }
>     (gdb) p SP_REF(obj)
>     Cannot access memory at address 0x7ffff7e09eb8
>     (gdb) info proc mappings
>     .
>     .
>     .
>     0x7ffff7e07000     0x7ffff7e09000     0x2000        0x0  rw-p
>     0x7ffff7e0a000     0x7ffff7e2a000    0x20000        0x0  rw-p
> 
> As you can see the memory address 0x7ffff7e09eb8 is not part of the
> mappings of the process as it lies between the above two listed
> mappings.

I'm not much into this and must hurry right now, but this seems
somewhat surprising. I'd have expected the memory to be in some
kind of read-only mapping...

Cheers
-- 
t

[signature.asc (application/pgp-signature, inline)]

Previous Next

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