[M3devel] SEGV mapping to RuntimeError

[Daniel Alejandro Benavides D.]

Hi all:
although this is not of my full understanding, CM3 JVM was supposed to handle in such a way the exceptions of jvm µ-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 handle that as in Modula-3 runtime per se, my believe is that you could do that 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 the scheduler from Modula-3, still this is more flexible nowadays I believe with multiprocessors, etc.
Similarly SPIN used or performed protection mechanism, like domain level, and at language level the heap freezes when handling untrusted code (even extra checked array bounds violation faults in non-Modula-3 code), so you have same runtime I believe for doing that too in Modula-3, again, is just another time of problem arises, perhaps this can be tried for thread stacks, etc and in kernel threads well as something alike, I really think could be done.
Thanks in advance

--- El lun, 21/2/11, Mika Nystrom <mika at async.caltech.edu> escribió:

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