[M3devel] SEGV mapping to RuntimeError

[Jay K]

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.
 
I suppose there might be an application that maps memory
gradually, as pieces of a buffer are hit. Might.
 
 - Jay
 
> To: m3devel at elegosoft.com
> Date: Sat, 19 Feb 2011 10:29:30 -0800
> From: mika at async.caltech.edu
> Subject: [M3devel] SEGV mapping to RuntimeError
> 
> 
> Dear m3devel,
> 
> For a while it has annoyed me that segmentation violations cause an
> unconditional program abort. I've changed that now so that (under user
> threads at least) we instead get a RuntimeError. Here's an example of
> the mechanism at work in an interactive Scheme environment. Consider
> the unhelpful interface and module Crash:
> 
> INTERFACE Crash; PROCEDURE Me(); END Crash.
> 
> MODULE Crash;
> 
> PROCEDURE Me() =
> VAR ptr : REF INTEGER := NIL; BEGIN
> ptr^ := 0
> END Me;
> 
> BEGIN END Crash.
> 
> Here's an example of what happens if you now call this from an interactive
> interpreter that catches the exception RuntimeError.E:
> 
> M-Scheme Experimental
> LITHP ITH LITHENING.
> > (require-modules "m3")
> #t
> > (Crash.Me)
> EXCEPTION! RuntimeError! Attempt to reference an illegal memory location.
> > (+ 3 4) 
> 7
> > 
> 
> I just realized I may have broken pthreads, let me go back and double-check it. 
> runtime/POSIX and thread/POSIX don't refer to the same thing do they...
> 
> Mika
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110219/e5497608/attachment-0002.html>