On Mon, 16 Feb 2026, [email protected] wrote: > On Sun, Feb 15, 2026 at 08:48:17PM -0500, Olivier Dion wrote: >> 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: > > [...] > > Thanks for the insight! > >> We could setup a SIGSEGV signal handler [...] > >> 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". > > That would already be friendlier than a raw SEGV, but still of course > still hard for someone without some idea of the internals to understand > what went wrong.
The problem is that we don't know if the memory access is: - A bug in libguile (e.g. offset by one error, corrupted lists, null pointer access) - A violation of the Scheme specification (e.g. using set-car! on a constant literal) And this is where the difficulty arise. What I think is necessary is to fork the faulty thread in the signal handler and pause. The child can then serialize some of the information needed for crash reporting, e.g. PID, TID, siginfo fields. Then, it execve a crash handler program. That crash handler program would be a very small C program that could use ptrace to stop the parent process entirely (including all threads) and inspect its memory. From there, it is straight forward to find the faulty instruction in the VM and the faulty address access in the .go and making a good crash report, before killing the parent process. It is also possible to do some stack unwinding if the debug symbols are present. Some caveat here: - This requires /proc to me mounted (usually the case, but not always in containers) - Might be difficult to do on other platforms - Conflict with GDB and other debuggers due to how ptrace works [...] -- Olivier Dion
