[M3devel] SEGV mapping to RuntimeError

[Mika Nystrom]

There is in fact a small problem with my change to the way SIGSEGV is
handled.  It now appears that bad memory references are all happening
in ThreadPosix.m3 (i.e., we've lost some of the debugging help of the
error message).

I'm not quite sure how to fix this although I'm sure all the bits are
around.  My guess is that instead of performing RAISE RuntimeError.E
in the thread switcher, the code ought to call RTHooks.Raise with an
argument derived from the faulting address as reported to the signal
handler.  This is probably quite easy, but does anyone know the 
right routines to call?  One would need to track down the routine that
faulted as well as the RT0 record corresponding to the exception
RuntimeError.E.

     Mika

Jay K writes:
>Letting any code run after a SIGSEGV is dubious.
>Imagine the heap is corrupted.
>And then you run more code.
>And the code happens to call malloc.
>Or printf to log something.
>=20
>I suppose there might be an application that maps memory
>gradually=2C as pieces of a buffer are hit. Might.