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 ;/
