[M3devel] SEGV mapping to RuntimeError

[Rodney M. Bates]

I don't know how relevant this is, but FWIW, I played with some patches in an
interactive program I have that catches its own assertion failures and recovers
from some of them.  I was already using RTProcess.RegisterExitor with my own
procedure.  I made the exitor just call RTException.Raise.  Then I deliberately
did a NIL deref inside a try block catching RTException.E and ignoring it.

It did prevent termination of my program.  But there were two other problems:

1) The SIGSEGV messages came out on the command line before the exitor was
    invoked.
2) After the exception was caught, the program was catatonic, without using
    CPU.

This is with pthreads.  I haven't figured out why the wait.  m3gdb seems to
be useless in looking at other threads than the one it happens to get into,
when using pthreads.

On 02/21/2011 08:12 PM, Mika Nystrom wrote:
> 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
>