Visual D seems to have a new bug

[Rainer Schuetze]

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.