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
