[M3devel] SEGV mapping to RuntimeError

[Mika Nystrom]

There are several issues here and yes this the RuntimeError.E exception
is taken either from SPIN or the CM3 JVM, I don't know which.

I only understand the user threads code so I have made that raise the
RuntimeError.E instead of dumping core on a segfault.  I think this is what
the CM JVM was supposed to do as well---but honestly I can't tell if that
work was ever completed.  They do support mapping various other runtime
errors (subrange mismatch, e.g.) into exceptions, and that works well.
However the segmentation fault mapping was not functional: there was no
other way of handling it than dumping core on the whole M3 environment
and runtime before my changes last week.

My last email was about a bug in my changes---not in the actual functionality
but the fact that if you *don't* catch the RuntimeError.E exception that
results from a bad memory reference, the runtime quits with a slightly
confusing error message, apparently implicating the threading system when
the bug is actually in normal, non-UNSAFE code.

     Mika

"Daniel Alejandro Benavides D." writes:
>Hi all:
>although this is not of my full understanding, CM3 JVM was supposed to hand=
>le in such a way the exceptions of jvm =B5-op fault script programs, given =
>that: there was a runtime above the CM3 runtime and besides having its own =
>spaces for stack, thread stacks and runtime machinery, loader, etc.
>Please just to advert this is and I guess was the case for CM3 JVM, if so, =
>let the system handle it in that way, why do you need to fully manage to ha=
>ndle that as in Modula-3 runtime per se, my believe is that you could do th=
>at for the language environment routines separately, that's why pragmas are=
> really useful. I don't believe it allowed to signal like in Modula-3 terms=
> threads but you could for instance lock a thread until you have time in th=
>e scheduler from Modula-3, still this is more flexible nowadays I believe w=
>ith multiprocessors, etc.
>Similarly SPIN used or performed protection mechanism, like domain level, a=
>nd at language level the heap freezes when handling untrusted code (even ex=
>tra checked array bounds violation faults in non-Modula-3 code), so you hav=
>e same runtime I believe for doing that too in Modula-3, again, is just ano=
>ther time of problem arises, perhaps this can be tried for thread stacks, e=
>tc and in kernel threads well as something alike, I really think could be d=
>one.
>Thanks in advance
>
>--- El lun, 21/2/11, Mika Nystrom <mika at async.caltech.edu> escribi=F3:
>
>> De: Mika Nystrom <mika at async.caltech.edu>
>> Asunto: Re: [M3devel] SEGV mapping to RuntimeError
>> Para: "Jay K" <jay.krell at cornell.edu>, m3devel at elegosoft.com
>> Fecha: lunes, 21 de febrero, 2011 19:01
>>=20
>> 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).
>>=20
>> 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=20
>> 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.
>>=20
>>      Mika
>>=20
>> 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.
>> >=3D20
>> >I suppose there might be an application that maps
>> memory
>> >gradually=3D2C as pieces of a buffer are hit. Might.
>> =0A=0A=0A