Should catch SIGSEGV, SIGBUS because broken unsafe code can otherwise

[larceny-trac-import]

Reported by: lth on Sat Dec 19 06:00:00 1998 089 v0.40 (981219 / lth) Priority: medium. Category: RTS / quality-of-implementation

Should catch SIGSEGV, SIGBUS because broken unsafe code can otherwise cause a core dump.

Notes: This is partly implemented in Rts/Sys/signals.c but not complete; a minor redesign of the exception handling system seems in order.

[larceny-trac-import]

Author: pnkfelix (I want to make sure that we think about whatever this is talking about when we revise the exception system for R6RS. . . )

[larceny-trac-import]

Author: will I don't think this has much (if anything) to do with the R6RS exception system.

This can wait, but will become more critical when we make it easier for users to run unsafe code.

[WillClinger]

If this is easy, we should do it. If it isn't easy, it would be good to know what the problems are.

[lars-t-hansen]

It probably isn't all that easy and the solution won't be portable. I think that at the time, my concern wasn't about the information in the core dump per se, just that we were crashing without a message, so the original report should read "... can otherwise cause a crash".

All that said, at the time we were (more or less) catching and handling SIGFPE for division-by-zero, so there was some support in this direction on Unix-like systems. It's my understanding that Larceny now performs an explicit zero check so that handling code may have been removed.

[jkoser]

So what is the desired behavior when we get a SIGSEGV or SIGBUS? Print a message before exit?

It seems to me that if we get one of those, there's a decent chance of memory corruption, and in that case it's game over anyway.

[lars-t-hansen]

I don't think we can reasonably hope to do anything for unsafe code that accesses already-allocated memory with a wild pointer although it's perhaps an interesting research problem to make something work with clever page protection tricks while in the ffi call :) Might be a useful debugging mode.

Printing a message "You've crashed" before exit is probably OK for user programs when there's no debugger available. Throwing an exception would be better but, as you say, the process is probably corrupted.

When there's a debugger available, printing a message is no better than what currently happens, maybe it's even worse because we lose the C level debuggability that comes from the crash. IMO, the most desirable behavior when a debugger is available might be to handle the signal and stop in the Scheme debugger with some way of inspecting the continuation. Continuing execution does not seem like a requirement though.