testcpp11unwind

# Destructor is run
testcpp11unwind:::call_A()
#> Error: oh no!
#> hello from the destructor!

# Destructor is NOT run
testcpp11unwind:::call_B()
#> Error: oh no!

Note that cpp_A() and cpp_B() on their own are seemingly innocuous code that a developer is likely to write without thinking twice about it.

The destructor of a doesn’t run in the cpp_B() case because:

call_B() sets up a try/catch through the entry macros
fn() calls unwind_protect() and sets should_unwind_protect = FALSE
R_UnwindProtect() is used to call call_A(), and a setjmp() is used to be able to recover from longjmp()s
call_A() sets up a try/catch through the entry macros
cpp_A() is called
a is created
stop() calls unwind_protect(), but should_unwind_protect = FALSE so it does NOT use R_UnwindProtect() or setjmp()
stop() ends up calling Rf_error(), causing a longjmp()
Because should_unwind_protect = FALSE, the longjmp() is not caught in stop(). Instead we jump alllll the way back to where fn() called unwind_protect() and R_UnwindProtect(). This skips over the cpp_A() frame where a should have been destructed on the way out. VERY BAD!

DavisVaughan/testcpp11unwind

testcpp11unwind