www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.debugger - Visual D seems to have a new bug

reply Brett <Brett gmail.com> writes:
Variables are not showing properly. Specifically the trouble I'm 
having is with this pointers.

I have a simple struct and toString and this shows in the 
watches/locals but it expands to not found:

-		this	0x0000028d3a7d12c8 {0x000000005da0e220}
-			0x000000005da0e220	
		x	D0001: Error: Expression couldn't be evaluated	

simply doing auto This = this;

This works.

I've noticed other weird issues in the watches and locals not 
showing variables.
Sep 30 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the trouble I'm having
 is with this pointers.
 
 I have a simple struct and toString and this shows in the watches/locals
 but it expands to not found:
 
 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220   
         x    D0001: Error: Expression couldn't be evaluated   
 
 simply doing auto This = this;
 
 This works.
 
 I've noticed other weird issues in the watches and locals not showing
 variables.
 


A test case would be helpful...

I can only suspect that 'this' is stored in some register, but that it
is not reflected in the debug information. It looks like your struct
contains a pointer, maybe the value shown doesn't point to existing
memory? Does `This` show the same pointer values, but proper fields?
Sep 30 2019
parent reply Brett <Brett gmail.com> writes:
On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote:

 On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the trouble 
 I'm having is with this pointers.
 
 I have a simple struct and toString and this shows in the 
 watches/locals but it expands to not found:
 
 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220
         x    D0001: Error: Expression couldn't be evaluated
 
 simply doing auto This = this;
 
 This works.
 
 I've noticed other weird issues in the watches and locals not 
 showing variables.
 


 A test case would be helpful...

 I can only suspect that 'this' is stored in some register, but 
 that it is not reflected in the debug information. It looks 
 like your struct contains a pointer, maybe the value shown 
 doesn't point to existing memory? Does `This` show the same 
 pointer values, but proper fields?


-		this	0x0000016ff0f6b588 {0x000000000001ffff}	P**
+			0x000000000001ffff	P*
-		This	{x=131071}	P

auto This = this;

This is not showing as a pointer, this is a double pointer and 
seems to be referring to the first value.

Not sure if the address is right, probably is, seems the problem 
is that this is being treating as a **.

I don't have any reduced test case now but it should be simple to 
do or find the bug I imagine.

It literally is just

struct P { long x; auto foo() { auto This = this; } }

type of thing with a bunch of other stuff that is irrelevant to 
the problem.

It shouldn't matter how P is being used(I am using pointers to P 
in arrays P*[] in some cases that may be throwing something off 
that is malformed already).

But clearly since `auto This = this` is correct, this is either 
1. A debugging map error(when it displays this automatically it 
screws up and dereferences it twice) or 2. Or most likely 1.

The reason being is that the code uses this and works fine so it 
is no actually dereferencing junk.

Recently you modified the code to fix a pointer bug with 
variables in the watch(null values I believe) and so chances are 
that screwed up this. It used to work fine so is a relatively new 
thing and the bug is clearly an extra dereferencing issue and 
only a "visual" problem.
Oct 01 2019
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/10/2019 17:41, Brett wrote:

 On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote:

 On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the trouble I'm
 having is with this pointers.

 I have a simple struct and toString and this shows in the
 watches/locals but it expands to not found:

 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220
         x    D0001: Error: Expression couldn't be evaluated

 simply doing auto This = this;

 This works.

 I've noticed other weird issues in the watches and locals not showing
 variables.


 A test case would be helpful...

 I can only suspect that 'this' is stored in some register, but that it
 is not reflected in the debug information. It looks like your struct
 contains a pointer, maybe the value shown doesn't point to existing
 memory? Does `This` show the same pointer values, but proper fields?


 
 -        this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P
 
 auto This = this;
 
 This is not showing as a pointer, this is a double pointer and seems to
 be referring to the first value.
 
 Not sure if the address is right, probably is, seems the problem is that
 this is being treating as a **.
 
 I don't have any reduced test case now but it should be simple to do or
 find the bug I imagine.
 
 It literally is just
 
 struct P { long x; auto foo() { auto This = this; } }
 
 type of thing with a bunch of other stuff that is irrelevant to the
 problem.
 
 It shouldn't matter how P is being used(I am using pointers to P in
 arrays P*[] in some cases that may be throwing something off that is
 malformed already).
 
 But clearly since `auto This = this` is correct, this is either 1. A
 debugging map error(when it displays this automatically it screws up and
 dereferences it twice) or 2. Or most likely 1.
 
 The reason being is that the code uses this and works fine so it is no
 actually dereferencing junk.
 
 Recently you modified the code to fix a pointer bug with variables in
 the watch(null values I believe) and so chances are that screwed up
 this. It used to work fine so is a relatively new thing and the bug is
 clearly an extra dereferencing issue and only a "visual" problem.
 


I cannot easily reproduce the issue, but it might already be fixed by
the same patch as the one avoiding crashes with pointers to empty arrays.

You can try to replace "c:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or
similar path depending on the VS version) with the
Appveyor artifact here:
https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts

This version also contains some of your recent suggestions.
Oct 01 2019
parent reply Brett <Brett gmail.com> writes:
On Tuesday, 1 October 2019 at 18:44:37 UTC, Rainer Schuetze wrote:

 On 01/10/2019 17:41, Brett wrote:

 On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze 
 wrote:

 On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the trouble 
 I'm having is with this pointers.

 I have a simple struct and toString and this shows in the 
 watches/locals but it expands to not found:

 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220
         x    D0001: Error: Expression couldn't be evaluated

 simply doing auto This = this;

 This works.

 I've noticed other weird issues in the watches and locals 
 not showing variables.


 A test case would be helpful...

 I can only suspect that 'this' is stored in some register, 
 but that it is not reflected in the debug information. It 
 looks like your struct contains a pointer, maybe the value 
 shown doesn't point to existing memory? Does `This` show the 
 same pointer values, but proper fields?


 
 -        this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P
 
 auto This = this;
 
 This is not showing as a pointer, this is a double pointer and 
 seems to be referring to the first value.
 
 Not sure if the address is right, probably is, seems the 
 problem is that this is being treating as a **.
 
 I don't have any reduced test case now but it should be simple 
 to do or find the bug I imagine.
 
 It literally is just
 
 struct P { long x; auto foo() { auto This = this; } }
 
 type of thing with a bunch of other stuff that is irrelevant 
 to the problem.
 
 It shouldn't matter how P is being used(I am using pointers to 
 P in arrays P*[] in some cases that may be throwing something 
 off that is malformed already).
 
 But clearly since `auto This = this` is correct, this is 
 either 1. A debugging map error(when it displays this 
 automatically it screws up and dereferences it twice) or 2. Or 
 most likely 1.
 
 The reason being is that the code uses this and works fine so 
 it is no actually dereferencing junk.
 
 Recently you modified the code to fix a pointer bug with 
 variables in the watch(null values I believe) and so chances 
 are that screwed up this. It used to work fine so is a 
 relatively new thing and the bug is clearly an extra 
 dereferencing issue and only a "visual" problem.
 


 I cannot easily reproduce the issue, but it might already be 
 fixed by the same patch as the one avoiding crashes with 
 pointers to empty arrays.

 You can try to replace "c:\Program Files (x86)\Microsoft Visual
 Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" 
 (or
 similar path depending on the VS version) with the
 Appveyor artifact here:
 https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts

 This version also contains some of your recent suggestions.


This did not fix it ;/ I'm not 100% sure I updated correctly but 
it seemed correct(The browser remembered the saved dir from last 
time and I just used it and overwrote the dll).

Surely this should be a simple bug to find? Somewhere in the code 
this is automatically watched and for some reason it's type is 
off.

Do you know the location of that code that you could paste a 
reference to? I'll look at it and see if I can see anything.

I wonder if you could easily modify Visual D so that one could 
"break" in to it to do some debugging. It might be much easier. 
If, for example, I could run a piece of code that somehow 
triggers debugging of Visual D around the code being debugged(a 
BP of a BP in some sense) then it might be easier. I realize that 
it doesn't quite work this way but if I could just get some 
VisualD code to pop up in another debugger running parallel then 
I could debug some of these problems myself. I have had no 
success building visual D myself so if there was a debug build 
that worked I could download that and use it.

There is definitely some weird dereferencing issue in the code.  
I'll eventually get around to making a test case but it won't be 
for a few days.
Oct 01 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02/10/2019 07:46, Brett wrote:

 On Tuesday, 1 October 2019 at 18:44:37 UTC, Rainer Schuetze wrote:

 On 01/10/2019 17:41, Brett wrote:

 On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze wrote:

 On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the trouble I'm
 having is with this pointers.

 I have a simple struct and toString and this shows in the
 watches/locals but it expands to not found:

 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220
         x    D0001: Error: Expression couldn't be evaluated

 simply doing auto This = this;

 This works.

 I've noticed other weird issues in the watches and locals not
 showing variables.


 A test case would be helpful...

 I can only suspect that 'this' is stored in some register, but that
 it is not reflected in the debug information. It looks like your
 struct contains a pointer, maybe the value shown doesn't point to
 existing memory? Does `This` show the same pointer values, but
 proper fields?


 -        this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P

 auto This = this;

 This is not showing as a pointer, this is a double pointer and seems
 to be referring to the first value.

 Not sure if the address is right, probably is, seems the problem is
 that this is being treating as a **.

 I don't have any reduced test case now but it should be simple to do
 or find the bug I imagine.

 It literally is just

 struct P { long x; auto foo() { auto This = this; } }

 type of thing with a bunch of other stuff that is irrelevant to the
 problem.

 It shouldn't matter how P is being used(I am using pointers to P in
 arrays P*[] in some cases that may be throwing something off that is
 malformed already).

 But clearly since `auto This = this` is correct, this is either 1. A
 debugging map error(when it displays this automatically it screws up
 and dereferences it twice) or 2. Or most likely 1.

 The reason being is that the code uses this and works fine so it is
 no actually dereferencing junk.

 Recently you modified the code to fix a pointer bug with variables in
 the watch(null values I believe) and so chances are that screwed up
 this. It used to work fine so is a relatively new thing and the bug
 is clearly an extra dereferencing issue and only a "visual" problem.


 I cannot easily reproduce the issue, but it might already be fixed by
 the same patch as the one avoiding crashes with pointers to empty arrays.

 You can try to replace "c:\Program Files (x86)\Microsoft Visual
 Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or
 similar path depending on the VS version) with the
 Appveyor artifact here:
 https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts

 This version also contains some of your recent suggestions.


 
 This did not fix it ;/ I'm not 100% sure I updated correctly but it
 seemed correct(The browser remembered the saved dir from last time and I
 just used it and overwrote the dll).
 
 Surely this should be a simple bug to find? Somewhere in the code this
 is automatically watched and for some reason it's type is off.
 
 Do you know the location of that code that you could paste a reference
 to? I'll look at it and see if I can see anything.
 
 I wonder if you could easily modify Visual D so that one could "break"
 in to it to do some debugging. It might be much easier. If, for example,
 I could run a piece of code that somehow triggers debugging of Visual D
 around the code being debugged(a BP of a BP in some sense) then it might
 be easier. I realize that it doesn't quite work this way but if I could
 just get some VisualD code to pop up in another debugger running
 parallel then I could debug some of these problems myself. I have had no
 success building visual D myself so if there was a debug build that
 worked I could download that and use it.


You don't have to compile Visual D, but mago:
https://github.com/rainers/mago

Ignore the readme, load MagoDbg_2010.sln into VS2013 or newer, and build
Expression/MagoNatCC for configuration "Debug Static DE|Win32". Then
replace the DLL in the VS debugger folder with
bin\Win32\Debug\MagoNatCC.dll.

If you hit an issue, you can start a new instance of VS with the mago
solution and attach its debugger to the other running VS (devenv.exe).

There is actually some automatic dereferencing going on (avoiding extra
nesting in watches) here

https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L213,
https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L315 and
https://github.com/rainers/mago/blob/master/EED/EED/EnumValues.cpp#L845

which might have gotten out-of-sync recently. I think I just noticed an
issue and triggered a new build on Appveyor.
Oct 01 2019
parent reply Brett <Brett gmail.com> writes:
On Wednesday, 2 October 2019 at 06:25:15 UTC, Rainer Schuetze 
wrote:

 On 02/10/2019 07:46, Brett wrote:

 On Tuesday, 1 October 2019 at 18:44:37 UTC, Rainer Schuetze 
 wrote:

 On 01/10/2019 17:41, Brett wrote:

 On Tuesday, 1 October 2019 at 06:12:42 UTC, Rainer Schuetze 
 wrote:

 On 01/10/2019 06:05, Brett wrote:

 Variables are not showing properly. Specifically the 
 trouble I'm having is with this pointers.

 I have a simple struct and toString and this shows in the 
 watches/locals but it expands to not found:

 -        this    0x0000028d3a7d12c8 {0x000000005da0e220}
 -            0x000000005da0e220
         x    D0001: Error: Expression couldn't be evaluated

 simply doing auto This = this;

 This works.

 I've noticed other weird issues in the watches and locals 
 not showing variables.


 A test case would be helpful...

 I can only suspect that 'this' is stored in some register, 
 but that it is not reflected in the debug information. It 
 looks like your struct contains a pointer, maybe the value 
 shown doesn't point to existing memory? Does `This` show 
 the same pointer values, but proper fields?


 -        this    0x0000016ff0f6b588 {0x000000000001ffff}    
 P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P

 auto This = this;

 This is not showing as a pointer, this is a double pointer 
 and seems to be referring to the first value.

 Not sure if the address is right, probably is, seems the 
 problem is that this is being treating as a **.

 I don't have any reduced test case now but it should be 
 simple to do or find the bug I imagine.

 It literally is just

 struct P { long x; auto foo() { auto This = this; } }

 type of thing with a bunch of other stuff that is irrelevant 
 to the problem.

 It shouldn't matter how P is being used(I am using pointers 
 to P in arrays P*[] in some cases that may be throwing 
 something off that is malformed already).

 But clearly since `auto This = this` is correct, this is 
 either 1. A debugging map error(when it displays this 
 automatically it screws up and dereferences it twice) or 2. 
 Or most likely 1.

 The reason being is that the code uses this and works fine 
 so it is no actually dereferencing junk.

 Recently you modified the code to fix a pointer bug with 
 variables in the watch(null values I believe) and so chances 
 are that screwed up this. It used to work fine so is a 
 relatively new thing and the bug is clearly an extra 
 dereferencing issue and only a "visual" problem.


 I cannot easily reproduce the issue, but it might already be 
 fixed by the same patch as the one avoiding crashes with 
 pointers to empty arrays.

 You can try to replace "c:\Program Files (x86)\Microsoft 
 Visual
 Studio\2019\Community\Common7\Packages\Debugger\MagoNatCC.dll" (or
 similar path depending on the VS version) with the
 Appveyor artifact here:
 https://ci.appveyor.com/project/rainers/mago/builds/27804605/artifacts

 This version also contains some of your recent suggestions.


 
 This did not fix it ;/ I'm not 100% sure I updated correctly 
 but it seemed correct(The browser remembered the saved dir 
 from last time and I just used it and overwrote the dll).
 
 Surely this should be a simple bug to find? Somewhere in the 
 code this is automatically watched and for some reason it's 
 type is off.
 
 Do you know the location of that code that you could paste a 
 reference to? I'll look at it and see if I can see anything.
 
 I wonder if you could easily modify Visual D so that one could 
 "break" in to it to do some debugging. It might be much 
 easier. If, for example, I could run a piece of code that 
 somehow triggers debugging of Visual D around the code being 
 debugged(a BP of a BP in some sense) then it might be easier. 
 I realize that it doesn't quite work this way but if I could 
 just get some VisualD code to pop up in another debugger 
 running parallel then I could debug some of these problems 
 myself. I have had no success building visual D myself so if 
 there was a debug build that worked I could download that and 
 use it.


 You don't have to compile Visual D, but mago: 
 https://github.com/rainers/mago

 Ignore the readme, load MagoDbg_2010.sln into VS2013 or newer, 
 and build Expression/MagoNatCC for configuration "Debug Static 
 DE|Win32". Then replace the DLL in the VS debugger folder with 
 bin\Win32\Debug\MagoNatCC.dll.


I was able to build and copy the file and all that but when I 
attach and add a BP on, say line 345 below the BP is missing and 
says symbols are not loaded. I took all the pdb's and put them in 
a directory and added the dir too the symbols dir in the VS 
options but it is still missing. Also the "modules" are not 
showing any symbols for mago... all visual studio stuff(mainly 
.net, not sure why they would be showing).

"This breakpoints will not currently be hit. Symbols not 
loaded"...

I use attach to process then find devenv.exe of the target D 
app(not the app itself but the visual studio process running it 
since I imagine that is the one running the mago dll).


I've copied the pdb's to the same dir as the mago dll's... Visual 
studio simply won't load them ;/ This is with the debug static 
build.

Any idea? Am I doing it wrong?


 If you hit an issue, you can start a new instance of VS with 
 the mago solution and attach its debugger to the other running 
 VS (devenv.exe).


yes, I can't get Bp's to work though ;/


 There is actually some automatic dereferencing going on 
 (avoiding extra
 nesting in watches) here

 https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L213,
https://github.com/rainers/mago/blob/master/EED/EED/EED.cpp#L315 and
https://github.com/rainers/mago/blob/master/EED/EED/EnumValues.cpp#L845

 which might have gotten out-of-sync recently. I think I just 
 noticed an issue and triggered a new build on Appveyor.


I tried but it doesn't seem to be working ;/
Oct 02 2019
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 02/10/2019 18:04, Brett wrote:

 I was able to build and copy the file and all that but when I attach and
 add a BP on, say line 345 below the BP is missing and says symbols are
 not loaded. I took all the pdb's and put them in a directory and added
 the dir too the symbols dir in the VS options but it is still missing.
 Also the "modules" are not showing any symbols for mago... all visual
 studio stuff(mainly .net, not sure why they would be showing).
 
 "This breakpoints will not currently be hit. Symbols not loaded"...
 
 I use attach to process then find devenv.exe of the target D app(not the
 app itself but the visual studio process running it since I imagine that
 is the one running the mago dll).
 


Copying the pdb should not be necessary because it is referenced by the
absolute path.

I suspect that you have selected "Managed code" only when attaching to
the process. You have to select/add "Native code".
Oct 02 2019
parent Brett <Brett gmail.com> writes:
On Wednesday, 2 October 2019 at 20:48:42 UTC, Rainer Schuetze 
wrote:

 On 02/10/2019 18:04, Brett wrote:

 I was able to build and copy the file and all that but when I 
 attach and add a BP on, say line 345 below the BP is missing 
 and says symbols are not loaded. I took all the pdb's and put 
 them in a directory and added the dir too the symbols dir in 
 the VS options but it is still missing. Also the "modules" are 
 not showing any symbols for mago... all visual studio 
 stuff(mainly .net, not sure why they would be showing).
 
 "This breakpoints will not currently be hit. Symbols not 
 loaded"...
 
 I use attach to process then find devenv.exe of the target D 
 app(not the app itself but the visual studio process running 
 it since I imagine that is the one running the mago dll).
 


 Copying the pdb should not be necessary because it is 
 referenced by the absolute path.


I copied just to be sure.(using the build environment to copy 
every build)


 I suspect that you have selected "Managed code" only when 
 attaching to the process. You have to select/add "Native code".


No ;/ It was automatic, I then set it to native and same problem.

;/ I tried again and it worked. I made sure to set native and 
managed. I thought I tried that but... it's still not loading but 
now it does show it and the info says that the image does not 
match.

Not sure why but at least it seems to be working now! I had to 
delete everything and start over. In any case, now I can play 
around with it and see what I can come up with ;)

Thanks!



I thought
Oct 02 2019
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 01/10/2019 17:41, Brett wrote:

         this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P
 
 auto This = this;
 
 This is not showing as a pointer, this is a double pointer and seems to
 be referring to the first value.


The double indirection looks bad. I don't think that mago adds
indirections, it only removes some to reduce clutter.

I suspect that the debug info is broken. The best tool for dumping it is
https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe
Oct 03 2019
next sibling parent Brett <Brett gmail.com> writes:
On Thursday, 3 October 2019 at 12:04:50 UTC, Rainer Schuetze 
wrote:

 On 01/10/2019 17:41, Brett wrote:

         this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P
 
 auto This = this;
 
 This is not showing as a pointer, this is a double pointer and 
 seems to be referring to the first value.


 The double indirection looks bad. I don't think that mago adds 
 indirections, it only removes some to reduce clutter.

 I suspect that the debug info is broken. The best tool for 
 dumping it is 
 https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe



I've noticed that the first entry seems to always be treated like 
a pointer no matter what it is. Has nothing to do with `this`. 
Strings, ints, etc....
Oct 03 2019
prev sibling parent reply Brett <Brett gmail.com> writes:
On Thursday, 3 October 2019 at 12:04:50 UTC, Rainer Schuetze 
wrote:

 On 01/10/2019 17:41, Brett wrote:

         this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P
 
 auto This = this;
 
 This is not showing as a pointer, this is a double pointer and 
 seems to be referring to the first value.


 The double indirection looks bad. I don't think that mago adds 
 indirections, it only removes some to reduce clutter.

 I suspect that the debug info is broken. The best tool for 
 dumping it is 
 https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe



That may very well be because I did just recently update dmd and 
this is when I noticed it... I'm not sure if I updated visual d 
around that time or not.
Oct 03 2019
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 04/10/2019 01:48, Brett wrote:

 On Thursday, 3 October 2019 at 12:04:50 UTC, Rainer Schuetze wrote:

 On 01/10/2019 17:41, Brett wrote:

         this    0x0000016ff0f6b588 {0x000000000001ffff}    P**
 +            0x000000000001ffff    P*
 -        This    {x=131071}    P

 auto This = this;

 This is not showing as a pointer, this is a double pointer and seems
 to be referring to the first value.


 The double indirection looks bad. I don't think that mago adds
 indirections, it only removes some to reduce clutter.

 I suspect that the debug info is broken. The best tool for dumping it
 is
 https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump/cvdump.exe


 
 
 That may very well be because I did just recently update dmd and this is
 when I noticed it... I'm not sure if I updated visual d around that time
 or not.


Could also be due to updates of Visual Studio 2019: I just noticed that
a function wasn't showing any locals. These reappear when setting the VC
linker debug option to "FULL". If you are using a visualdproj project
you currently have to add -L/DEBUG:FULL to the additional command line
options to get the same result.
Oct 04 2019