Menu
Search

Forums

Forum Index

Thread overview
-checkaction=C - Debugger out of sync?
Jan 25, 2022
frame
Jan 27, 2022
frame
Jan 27, 2022
frame
Jan 27, 2022
Rainer Schuetze
January 25, 2022
Gravatar of framePosted by frameReply
frame
Gravatar of frame


Reply

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?

January 27, 2022
Gravatar of framePosted by frame
in reply to frame		Reply
frame
Gravatar of frame
Posted in reply to frame


Reply

@Rainer Schuetze
I quote this (you have sent me somehow a private email)

>

If your invariant is called from the GC during finalization, it might
have to do with the debugger executing code to show structs or ranges.
Are you using the visualizer methods __debugOverView, __debugExpanded,
etc.? Are ranges displayed in your Auto/Local/Watch windows?

No, I don't.

>

You can try to disable implicit code execution by the debugger in
Tools->Options->Debugging->Mago by unchecking options "Call
struct/class..." and "Call range methods".

Yes, the option Call range methods causes the problem! Is that still experimental in VisualD 1.2.0? Please do not enable it by default then.

January 27, 2022
Gravatar of framePosted by frame
in reply to frame		Reply
frame
Gravatar of frame
Posted in reply to frame


Reply

On Thursday, 27 January 2022 at 17:32:03 UTC, frame wrote:

>

@Rainer Schuetze

Forgot to say thank you =)

January 27, 2022
Gravatar of Rainer SchuetzePosted by Rainer Schuetze
in reply to frame		Reply
Rainer Schuetze
Gravatar of Rainer Schuetze
Posted in reply to frame


Reply

On 27/01/2022 18:32, frame wrote:
> @Rainer Schuetze
> I quote this (you have sent me somehow a private email)

Sorry, I still screw this up too often since the default/button order has changed in Thunderbird.

> 
>> If your invariant is called from the GC during finalization, it might
>> have to do with the debugger executing code to show structs or ranges.
>> Are you using the visualizer methods __debugOverView, __debugExpanded,
>> etc.? Are ranges displayed in your Auto/Local/Watch windows?
> 
> No, I don't.
> 
>> You can try to disable implicit code execution by the debugger in
>> Tools->Options->Debugging->Mago by unchecking options "Call
>> struct/class..." and "Call range methods".
> 
> Yes, the option `Call range methods` causes the problem! Is that still experimental in VisualD 1.2.0? Please do not enable it by default then.

It's a bit dangerous because executing code automatically can mutate your program state.

The default has been changed quite some time ago (https://github.com/rainers/mago/commit/8ce1bb37818ea38e88ec8ecf2439383b592fca46), so you probably picked up the enabled state as an early adopter.