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

On Tue, 21 Oct 2025, [email protected] wrote:
> On Tue, Oct 21, 2025 at 02:04:54AM -0400, Nikolaos Chatzikonstantinou wrote:
[...]

> 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...

I could reproduce and it is indeed in a read-only mapping:

  $ cat test.scm
  (set-car! '(0) 1)
  $ guix shell guile guile:debug gdb
  $ guild compile test.scm
  $ gdb --args guile test.scm
  (gdb) run
  (gdb) layout asm
    0x7ffff7f4004b <vm_regular_engine+4011> mov    %rcx,(%rdx,%rax,8)
  (gdb) p/x $rdx
  $1 = 0x7fffef754118
  (gdb) info proc
  process 29858
  (gdb) shell cat /proc/29858/maps | grep 7fffef754
  7fffef754000-7fffef764000 r--p 00000000 00:18 136205162

We could setup a SIGSEGV signal handler.  Since this is triggered
asynchrounsly by the hardware, as opposed to other signals, it would be
very much thread-safe to handle things in the signal handler itself.
There is also a way (at least on Linux) to distinguish the signal
provenance (bad kill vs actual hardware signal).

I guess the proper thing to do would be to stop every other threads and
print something nice along:

  Access to read only memory at location 0x7ffff7f4004b, which is mapped
  in 7fffef754000-7fffef764000 r--p 00000000 00:18 136205162 test.go

before exiting "gracefully".

If more info is available, it would be nice to point out the location in
the source-code.  Probably doable by looking the instruction pointer at
that point.

Thanks,
Olivier
-- 
Olivier Dion