Visual D debugging messed up

[Rainer Schuetze]

On 01/06/2018 09:00, IntegratedDimensions wrote:
>> 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 disabled the plugin and could not reproduce the issues. Today It 
> happened! Exactly the same behavior.
> 
> So, unless this is a VS issue, it is a VD issue.
> 
> Note that it pops up an error box that says no symbols have been loaded 
> for this document but also gives the document name and line number 
> except it says character 1...
> 
> So this is getting in to VD I imagine.
> 
> I mean, VD surely has to inform VS that the BP on a line is valid? If so 
> then that code must be buggy. Just putting a bunch of breakpoints on a 
> document will eventually give that bug... although, the plugin I used 
> seemed to exacerbate the problem.
> 
> I have other problems with the BP's.
> 
> If I am debugging and remove a BP, sometimes it reappears after stopping 
> the debugger. I have to restart VS for normal behavior to come back. 
> Seems to apply to all BP's.
> 
> Also, sometimes BP's do not show or show up depending on if actively 
> debugging or not.
> 
> I've never experienced this with Visual Studio's C++ or C# side of 
> things so I imagine it is a VD issue. Probably some simple bug or two in 
> the BP code.

This is the only interface implemented by the debugger plugin: 
https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.debugger.componentinterfaces.idkmlanguageexpressionevaluator?view=visualstudiosdk-2017

Breakpoints are handled by the VS debugger reading the PDB file. You 
might want to blame the compiler for not emitting exact line number 
infos, though.

>> You mean variables that start with a double underscore? Can you show 
>> an example?
> It would just be a picture. I'm looking at it right now
> 
> _TMP1922
> _TMP1923
> _TMP1924
> 
> all longs with very large values, looks random. These are probably the 3 
> nested loops I have.

The compiler should have used double underscores here (these are 
reserved for the compiler), otherwise the symbols might clash with user 
symbols.

> 
> 
>>
>>> 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?
> 
> No, but I have see that in the past.

Should be fixed since dmd 2.072.

>>
>>>
>>> 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.
> 
> But these are local to the current executing code. This maybe related to 
> the BP bug.
> 
>>>
>>> 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.
> 
> Usually it is useless double indirection making one click twice to open. 
> Since the debugger doesn't remember expanded variables between runs it 
> can require expanding objects many times just to see whats going on.
> 

I guess the additional line can be removed if the pointer also shows the 
abbreviated display value of the pointee (C++ does this, too).