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

--GTd4fxA1BVTyXbcf
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 w=
rote:
> [...]
>=20
> > 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...
>=20
> 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:
>=20
>   Access to read only memory at location 0x7ffff7f4004b, which is mapped
>   in 7fffef754000-7fffef764000 r--p 00000000 00:18 136205162 test.go
>=20
> 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.

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

Sound like a lot of work, but that would be totally great, of course :)

Cheers
--=20
tom=C3=A1s

--GTd4fxA1BVTyXbcf
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCaZLMogAKCRAFyCz1etHa
Rh+/AJ9XmjOI09UMjKV8OucypXUnx4gspACePzuEZWyqDCQri78acTIWAQXF5ss=
=u8H8
-----END PGP SIGNATURE-----

--GTd4fxA1BVTyXbcf--