Visual D debugging messed up

Fri Jun 1 07:00:39 UTC 2018

On Saturday, 26 May 2018 at 07:16:01 UTC, Rainer Schuetze wrote:
>
>
> 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.
>

yes.

> 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.

I'm sure you don't have the time but it might be a good idea to 
create a long term project where you develop(maybe something 
you've always wanted to do) where you spend a few minutes a week 
on. As you progress in the project and it becomes more complex 
you will probably run in to many bugs and ideas. Since you know 
the most about the extension it would be easiest for you to do 
the fixes. Just a suggestion, I'm sure you've got better things 
to do and I appreciate your work on VD, it can just be a bit 
annoying since I am use to the VS side of things which behave a 
bit better. If VD wasn't close to emulating them it wouldn't be 
as much a problem... expectations I guess... ;)

>> 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 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.

>> 
>> 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?

I can't seem to get a simple example to work. It might have been 
solved or related to the BP issue.

>
>> 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?
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.

>
>> 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.

>
>> 
>> 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.

>> 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.