In Visual Studio I can step into a thread and hold on a while. By
resuming the next instruction some invariant kicks in and throws
an error but it doesn't hold the thread in the debugger - I just
see the error on the output.
The debugger is still active but now running from
`rt.lifetime.finalize_struct(...)` (at least this is shown in the
stack window) while executing the next step of my user code in a
already half destroyed struct.
Setting a breakpoint on the invariant assert does not work. In
detail it's some Schrödingers assert:
If I set a breakpoint without holding the thread on, nothing
happens and all variants are fine. If I hold the thread on with
the breakpoint set and then resume with the next step, also no
error appears. But if I do the same with disabled breakpoint, the
error is thrown in the output.
It's the same thread, I checked it with GetCurrentThreadId().
Also the invariant is in the same thread checked, so the debugger
is somehow out of sync while the program flow is ahead.
Then I checked that I have supplied `-checkaction=C` on the main
app while a DLL was compiled with default settings. After
changing the DLL, the error disappeared. Is this just a
coincidence or can `-checkaction` cause a stack corruption or
something?
- -checkaction=C - Debugger out o... frame via Digitalmars-d-debugger
-
