ctrl+c and destructors

Sean Kelly sean at invisibleduck.org
Wed Oct 2 12:07:39 PDT 2013


On Oct 2, 2013, at 11:08 AM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

> On Wed, Oct 02, 2013 at 10:36:08AM -0700, Sean Kelly wrote:
>> On Oct 1, 2013, at 10:12 PM, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
>>> 
>>> Now, having *druntime* throw an exception upon ctrl-C is something
>>> totally different, and yes it will require some kind of scaffolding/hack
>>> to make it work, 'cos the exception must propagate outside of signal
>>> handler context.
>> 
>> I believe the way this currently works is [...]
> 
> Wait, this *currently* works?!

Oops.  I thought the hack for this was integrated ages ago, but I don't see it.


>> [...] by dynamically modifying code at the point the SEGV occurred,
>> which first patches up the code that was modified and then throws.
> 
> I thought the hack posted in the thread deadalnix linked to was to have
> the signal handler "corrupt" the stack -- i.e., modify it so that the
> return address is redirected to a segfault handler. Thus, as soon as the
> signal handler returns (and leaves signal handler context), instead of
> returning to its original caller it "returns" to the segfault handler
> instead, which can then set things up properly for stack unwinding and
> throw an exception (or Error as the case may be).

Yes.


>> But if the SEGV was inside a system call, you could be in serious
>> trouble, since that code isn't exception safe.
> 
> Well, SEGV itself is already serious trouble. :P  I don't think there's
> any safe way to "recover" from a SEGV, since it indicates that something
> has gone horribly wrong in a way the code can't handle.

It depends why and where, really.  See my reply to Walter.


> I think the OP's original point was how to ensure certain cleanups
> always ran (e.g. switch terminal back to normal teletype mode when the
> program has been running in ncurses mode). Well, there is no guarantee
> that it will run, due to the nature of segfaults, but assuming that the
> dtors concerned are high enough up the call stack to not be affected by
> Errors bypassing dtors due to being inside nothrow functions, it
> *should* work in the general case. Obviously, the program should never
> try to catch a SegfaultError and attempt to "recover" from it, since the
> program is already horribly screwed up by that point.

Yes, trying to recover from a thrown Error is rarely a good idea.  About the only one I'd consider trying to recover from is an OutOfMemoryError, and even then I'd be more inclined to assume a memory leak and just let the process die and restart.


More information about the Digitalmars-d mailing list