void* shows 0x0000000000 in debugger

[TurkeyMan]

I've started writing some code, fresh VS install, latest version. I'm noticing heaps of regressions in general. Stability is just not where it used to be.

Here's one for now:

    HANDLE hCom = INVALID_HANDLE_VALUE;
    hCom = CreateFile("COM3\0"w.ptr, GENERIC_READ | GENERIC_WRITE, 0, null, OPEN_EXISTING, 0, null);
    if (hCom == INVALID_HANDLE_VALUE)
    {
        writeln("CreateFile failed with error %d.\n", GetLastError());
        return;
    }

Step through that code; notice that hCom says 0x0000000000000000 at all times no matter what the actual value. You can see the real value with:

    size_t x = cast(size_t)hCom;

And then hover x, and you'll see the proper value.

Also notice that the hovering over the enum INVALID_HANDLE_VALUE does not show its value. Hovering enum's like this used to work.

[thewilsonator]

Are you able to verify if this is (or is not) an issue with the generated PDB (which compiler?) rather than visuald?

[TurkeyMan]

Not confirmed. DMD 2.106. Has there been activity in DMD's debuginfo output?

[rainers]

Hi Manu. I guess you are using VS 17.8, Visual D 1.4.0-beta2?

Step through that code; notice that hCom says 0x0000000000000000 at all times no matter what the actual value.

I cannot reproduce here. Can you show the full code? Maybe the debug info of surrounding code affects this, e.g. there might be another declaration of hCom elsewhere in the function, but in a different scope.

Also notice that the hovering over the enum INVALID_HANDLE_VALUE does not show its value.

I can reproduce this in VS2022 while debugging, works during normal edits. VS 2019 still works, too. IIRC there is a (slightly abused) callback to enable this for compile time values that might no longer work.

[TurkeyMan]

I'm on VS 17.7.3. Yeah; Visual D 1.4.0-beta2

It fails in this test. Pretty minimal:

void main()
{
    import core.sys.windows.windows;

    HANDLE h = INVALID_HANDLE_VALUE;
    if (h != INVALID_HANDLE_VALUE) // put breakpoint here
        return;
}

I'll poke around a bit more.

Separate to that, I have some weird long freezes going on from time to time.

[rainers]

I recently discovered another issue, supposedly when running Win11: https://github.com/dlang/visuald/issues/261#issuecomment-1859176858

Maybe try disabling 'Tools->Options->Debugging->General->Load debug symbols in external process.

[TurkeyMan]

I already found that thread and disabled that option. Before I did that it was completely unusable, like totally broken. It would lock up the VS process and burn RAM at an alarming rate... increasing 1GB ram usage every couple of seconds. It could start debugging, and you could step, but hovering to evaluate a variable would cause it, and clicking the stop-debugging button would also lock it up... so I couldn't end any debug session without terminating the VS processing and restarting. Something's really wrong over there! :P

[rainers]

Maybe also fixed with other crash fixes, please try https://github.com/dlang/visuald/releases/tag/v1.4.0-rc1

[TurkeyMan]

Nope, sadly this isn't fixed. Almost everything else I've complained about is fixed now though, so that's a huge step forward! How can we isolate this issue?

Length is 8:

Now I enable hex display:

Length now shows zero:

All pointers are always null. See here; vfptr shows null, all the method function pointers are null:

There's also a MonoTime in there, with an integer member _ticks, which shows null when switching to hex view.

So, the fact that integers show their value normally but then show zero when switching to hex view, and pointers always show zero, makes me wonder if it's something about hex view specifically rather than visualising pointers?

[rainers]

Thanks for the screenshots, they showed that you don't have the option "remove leading zeroes from hex values" under Tools->options->Debugger->Mago enabled. This triggered a bug with displaying 64-bit values. Until the fix is released, enabling that option should help.

[TurkeyMan]

Oh great, I like leading zeroes in hex values :) Weird that such a thing happened recently... it used to be fine.