Visual D debugging messed up

[Rainer Schuetze]

On 23/05/2018 19:27, IntegratedDimensions wrote:
> On Monday, 7 May 2018 at 06:32:54 UTC, Rainer Schuetze wrote:
>>
>>
>> On 02/05/2018 21:56, IntegratedDimensions wrote:
>>> Lots of temp variables and breakpoints are not hit: says missing 
>>> symbols but then next line works fine. Sometimes the stack trace 
>>> doesn't work, sometimes it does. Won't break sometimes if the BP is 
>>> the last line of a block. Everything latest version and fresh install 
>>> and in x86 mode.
>>
>> To hide the temporaries go to Tools->Options->Debugging->Mago and 
>> enable "Hide compiler generated symbols".
>>
>> If you are using VS2013 or later, I'd recommend selecting the "Visual 
>> Studio" debug engine, as this has the mago D expression evaluator 
>> plugged into the native VS debugger for better integration.
>>
>> For stacktraces, you can sometimes end up in a system call where the 
>> debugger doesn't know how to walk the stack. Usually loading the 
>> symbols from the Microsoft symbol server helps here.
>>
>> If there is some strange things happening regarding breakpoint 
>> positions, that's likely inaccurate debug information emitted by the 
>> compiler. It would be good if you could isolate examples and post them 
>> to bugzilla: https://issues.dlang.org/
> 
> It really is messed up!

There are a number of variables that affect the debug experience, e.g. 
VS version, compiler dmd/LDC, compiler version options used, debug 
engine used. See http://rainers.github.io/visuald/visuald/Debugging.html 
for some information about that. Best to provide information what you 
are using.

I assume you are using what is currently assumed best: VS2015+ with dmd 
2.077+, VS debug engine with debug info suitable for mago.

You can also add -gf to the command line, next version of Visual D will 
have that as a project option, too.

In this mode, the mago extension for D just enumerates locals and 
evaluates expressions, everything else is the same as the C++ debugger 
including breakpoint handling.

> 
> I have loops who's loop counters shown in the auto's clearly has the 
> wrong values(using a local copy has the right value).

> and even weirder bug! If I put a BP on a line I get missing symbols 
> loaded. If I move the cursor a few pixels higher but on the same line I 
> get the BP!! I know you won't believe me!!
> 
> I know! I bet! How can a few pixels matter?
> 
> I think Visual D needs a work over. Getting lots of strange bugs and 
> behaviors. It's so close to being a good IDE but I struggle using it.
> 
> Anyways, here's the proof since you don't believe me!
> 
> Do you actually use visual D for any serious development? I ask that 
> because I imagine if you did you would surely run in to these problems. 
> I doubt I'm the only one.
> 

Nothing serious, but mostly Visual D itself and dmd.

> Proof:
> https://ibb.co/isnhBT
> 
> 
> Using latest everything installed relatively fresh. Happens everywhere 
> but not all lines of code behave this way or I just get lucky clicking 
> most of the time. The error is no symbols have been loaded for the 
> document. I do have some plugin that shrinks lines that empty and maybe 
> that has something to do with it(shouldn't but if it does maybe there is 
> a calculation error in determining the line... although that invalid BP 
> still shows up on the correct line)

I've never seen something like this. I suspect it is caused by your 
additional plugin. That's not functionality covered by any of the D 
specific extensions, you will have the same issues in C++.

> 
> I have a list of complaints:
> 
> 
> 1. For loops and blocks do not break properly.
> 
> for(...) {
> }
> ----;
> 
> putting a BP on the line ---- will break in to the for loop so any 
> continuation of the debugger will hit the BP for each loop iteration. 
> Easy work around but kinda a pain. Seems to be that lines are calculated 
> a bit wrong in some cases(off by 1 error)... maybe related to the bug 
> above.

That very much depends on the debug info generated by the compiler. It's 
a bit problematic without braces (can happen with C++ aswell), but 
AFAICT it should work with braces. Can you provide a complete example?

> 2. Still getting temp variables, visual studio debugger shows less but 
> still some.

You mean variables that start with a double underscore? Can you show an 
example?

> 3. Some variables are returning invalid results(this is a bigger problem 
> but I can't seem to pin down why or some demo code).
> 
> Best I can tell is that I have several blocks that are basically copies 
> and using the same identifiers. Maybe the debugger is displaying the 
> wrong one which expired.
> 
> If I have a for loop like for(int j = 0; j < 100; j++) { auto k = j; }
> 
> the debugger will show j = 4324532 or something inside the loop similar 
> to how it will show junk before the variable is initialized. k shows the 
> correct value... so this is a display issue.
> 
> It might be better not to display variables when they are not in scope too.

Using the same variable name multiple times is problematic. The debug 
info emitted by dmd should specify the scope of the variables, but if it 
fails there is nothing the debugger can do to find the correct one. Do 
you see the same variable listed multiple times in the locals window?

> 
> 4. Watch window does not work well. Some variables simply will not be 
> valid.
> Going to 3, putting those variables in the window also returns the wrong 
> values;
> 

Global variables have to be specified fully qualified.

> 
> 5. In the watch or auto window for many types it shows odd stuff:
> https://ibb.co/gXuhd8
> 
> Note the blank lines.
> 
> The blank lines show good useful values but adds additional lines. It 
> might be better to consolidate the blank line with the line above it(the 
> main line) which only shows the address. addr - info or info (addr). 
> Usually one doesn't care about the address of a standard variable so it 
> shouldn't be shown first... but
> still easy to see.

I agree, the additional line can be annoying, but it is also sometimes 
useful, e.g. with a pointer to a string, you don't want to expand the 
array of characters immediately.

> 6. Multiple openings of the same file. Not sure why this is happening 
> but A.d will be open twice in the editor sometimes.

I think I've seen this, too, but AFAICT this happens with C++ too. I 
suspect it is because the same file is opened using different paths, 
e.g. with some relative path elements inside.

> Maybe I will get around to making some demo program but it will be many 
> weeks. Busy at the moment.
> 
> Seems like Visual D is a bit out of date with either the compilers or 
> Visual Studio or maybe it is a simple but.
> 
> 7. I'd really love a refactoring feature. I'm having to use search and 
> replace and that is not very code smart and error prone.
> 

We can think about it once we have a reliable semantic engine. 
Unfortunately that's not so easy.