You appear to be correct.
I am able to successfully run code similar to this example.
Looking at the SBCL sources I got the wrong impression that SIGSEGV
would not be handled
using the condition system. Wrong conclusion.
Gábor Melis wrote:
On Lunes 20 Abril 2009, Lynn Quam wrote:
It appears that in CMUCL it possible to handle SIGSEGV conditions.
(defun mmap-anonymous-region (size prot)
(unix::unix-mmap nil size prot (logior UNIX:MAP_ANONYMOUS
unix::MAP_PRIVATE) nil 0))
(defparameter *mmap-sap* (mmap-anonymous-region (* 4
(SYS:GET-PAGE-SIZE )) unix::PROT_NONE))
(handler-case (progn (unix:unix-mprotect *mmap-sap* (* 4
(sys:get-page-size )) unix::prot_read)
(setf (sys::sap-ref-32 *mmap-sap* 0) 1))
(unix:unix-mprotect *mmap-sap* (* 4 (sys:get-page-size ))
(setf (sys::sap-ref-32 *mmap-sap* 0) 1)
Has SBCL diverged from CMUCL in this regard?
This does not _resume_ the code that caused the fault. I probably took
your original question too literally and even then the answer was quite
wrong. Similar code should work on sbcl too, at least after adding
mprotect to sb-posix, but that does not allow you to actually resume
Signalling memory-fault-error with cerror in interr.lisp would allow you
to unprotect the page, do whatever is needed, and continue. However,
the reported fault address is not reliable on multithreaded builds as
it's passed via a global variable.