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.

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/

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!

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.

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

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

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.

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;


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.

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

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.


Thanks for you time!

Another issues is that the watch/auto's are arounding doubles.

I have a value that is like 4.999953943 and it shows 5.

I'd rather see at least several digits. This is because when I cast it to int I get 4 and the original shows 5 and it is confusing where the 1 went when one expects to see higher precision... there is plenty of rooms to show more digits so no reason to round... it is a double after all but looks like an int in the watch window.

Any arrays are very verbose:
https://ibb.co/gCVwO8

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.

On 23/05/2018 22:46, IntegratedDimensions wrote:
> Another issues is that the watch/auto's are arounding doubles.
> 
> I have a value that is like 4.999953943 and it shows 5.
> 
> I'd rather see at least several digits. This is because when I cast it to int I get 4 and the original shows 5 and it is confusing where the 1 went when one expects to see higher precision... there is plenty of rooms to show more digits so no reason to round... it is a double after all but looks like an int in the watch window.

I could reproduce that with a slightly larger number of '9's. Agreed, it should not round. I've changed that to always show the full number of digits relevant for the type (float/double/real).

On 24/05/2018 00:58, IntegratedDimensions wrote:
> Any arrays are very verbose:
> https://ibb.co/gCVwO8
> 
> 

This is an array of tuples, which are effectively structs as shown. Nothing wrong about arrays AFAICT, but given that the field names of tuples can be considered "internal", the debugger could omit their names.

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.

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