Corrupt Unwinding on Errors

Eyal Lotem eyal at weka.io
Tue Jan 22 08:13:34 UTC 2019


Hi,

I've hit a serious bug due to skipped dtors when errors are being 
thrown.

Whether dtors will run or be skipped is quite unpredictable, as 
it depends on `nothrow` inference[1].

dtors are often absolutely crucial for program correctness, and 
skipping them is very dangerous.

Thus, unwinding while skipping dtors may easily create 
corruption, so I'll term this "corrupt unwinding".

During corrupt unwinding, running scope() code is dangerous - as 
it runs in a potentially corrupt state, and indeed a PR exists to 
not run scope() code in this state [2].

The question is, why have corrupt unwinding at all?

If errors thrown should not properly unwind - why not call a 
tls-installed handler before terminating the program (with no 
unwinding)?

If errors do unwind - why not run the dtors and allow actual 
recovery? The performance cost for predictable, sane semantics is 
well worth it.

Side-note: resuming execution after corrupt unwinding is rarely 
practically possible in non-trivial programs. Knowing the effects 
of all potentially skipped dtors in all program and library code 
- especially as the program is maintained over time - is 
impractical.

[1] https://issues.dlang.org/show_bug.cgi?id=19602

[2] https://github.com/dlang/dmd/pull/6896



More information about the Digitalmars-d mailing list