Templated function not displaying templated variables correctly in watch window

[luis-reyes-a]

Hey, first off congratz on release!

Anyways, I have this templated function that creates a "T obj", where 'T' is the template typename.
Inspecting "obj" in the watch window shows nothing. Doing "(T *)&obj" says T is an unknown identifier. I thought maybe template support isn't their yet but what's interesting is that explicitly casting "&obj" to the instantiated type only shows parts of the struct members ... not all. Here are pictures of watch window in raddbg and visual studio

[ryanfleury]

What version are you running? Can you see if the same issue persists on the newest commit in master? I've been shaking out some type info issues this weekend; the Microsoft linker tends to keep stale types around, which may explain the missing fields, and the seemingly-two copies of Crazy_Struct, and I recently fixed a bug with recently-added-or-changed types failing to evaluate members altogether.

If you pull and build to check this, please rebuild your own program too, to ensure raddbg regenerates the debug info.

[luis-reyes-a]

Upgrading to latest version did in fact fix it! Sorry, didn't check for newer version since usually software doesn't get updated this fast!

On the latest exe release, there seems to be a weird rendering thing going on in the watch window in the pic here

However I just cloned the latest branch, built, and ran it and am not getting that rendering problem? Just mentioning it in case you didn't explicitly fix it and it's just for some reason not showing up in latest build.

Thanks!

[ryanfleury]

Thanks for the heads up! Yeah, I have noticed that before, although strangely enough, not only in RADDBG. So I'm not sure if it has to do with my own bugs in src/font_cache, or if it's someone else's bug, or some combination of the two. For now I'll close this issue (since it was originally about something else), but I'll keep my eye out for more occurrences of that.

If you keep seeing that issue, or if you find a solid repro, then please open another issue along with e.g. a RenderDoc capture of the problem, along with your computer's specs (e.g. GPU, driver versions, and so on).

Thanks!

[GloriousPtr]

I'm still facing this issue with eastl::shared_ptr where ref.ref_count_sp is not shown correctly.

This is how ref_count_sp looks

Version: 0.9.3 Alpha

[GloriousPtr]

Turned out eastl::atomic has a parent so I guess it can be related to #48
Sorry for the false positive, will wait for that one to be fixed and validate this again.

[GloriousPtr]

Tried e2e1382 but this seems like a completely different issue than #48.

Check CameraConstantBuffer

[ryanfleury]

Whoa, yeah, that is weird & definitely a different issue - RADDBG is using totally the wrong type info (even though it is visualizing the correct type's name, ArcEngine::ConstantBuffer?). To help me narrow this down, can you determine if this same issue occurs after deleting the PDB/RADDBG files for this build, and re-running?

[GloriousPtr]

No luck, tried with deleting both PDB and RADDBG files.
Also, I just noticed many of my pure virtual classes are behaving like that.
Will confirm in a while.

[ryanfleury]

That sounds like exactly the kind of C++ thing that we haven't tested very much, so glad we're hitting this now - I'll work on getting this all straightened out.

[GloriousPtr]

Here's the trivial example:
It's happening as long as parent class has any virtual function (pure or not doesn't matter)

[ryanfleury]

Great! Reproduced. I don't have the crazy eastl:: types but I can confirm that the pure-virtual type is redirecting to a totally different type, for some reason... debugging now!

[ryanfleury]

@MohitSethi99 As of my newest commits, the debugger should no longer display incorrect type info for pointers to pure-virtual classes, but it will not resolve base class pointers to their appropriate derived class types (based on the vtable function pointer), in the same way that VS does. That feature is a bit more involved; I've made significant progress but not quite done yet. Just giving you an update.

(If it doesn't work the first time, this may be because part of the fix involved a change to the PDB -> RADDBG converter. Before reporting extra issues, just run the converter again by deleting your existing .raddbg files if needed, just in case the issue has already been resolved.)

[GloriousPtr]

Thanks for quick fixes.
Can confirm pure virtuals are not showing wrong data.
However child is not showing the parent's variables (pure or not doesn't matter).

Pure virtual:

Non pure virtual

If I remove virtual methods then it's working as expected.

[ryanfleury]

Okay, that issue should be fixed as of a0a6fc0. Still working on auto-casting to the derived type based on the vtable pointer, stand by...

Thanks for bearing with me!

[GloriousPtr]

Working as expected now, no worries, please take your time :)
And thankyou for this awesome debugger!

[ryanfleury]

Wrapping up now. Base class pointers to derived class instances should shortly be detected by the debugger, implicitly casting the pointer to the derived type automatically (this can be casted away to the base class type if needed).

20240117_114434.mp4

[ryanfleury]

Alright, that is in as of d3931fd. Closing this issue now.

[GloriousPtr]

Thanks for all your hard work!
Everything seems to be working except the derived pointer conversion in non virtual inheritance case.

[ryanfleury]

Yeah @MohitSethi99, this case is - as far as I know - effectively not analyzable from a debugger, because there is no virtual table pointer implicitly inserted by the compiler in an instance of Pure. The only way to use the actual Child contents is to either explicitly cast it (which can be done in the watch window), or to have a virtual function (which then adds a virtual table pointer, which can be used to auto-cast to a derived pointer).

Visual Studio has the same behavior in this case:

[GloriousPtr]

Sorry about naively pointing to the issue without checking in VS and thanks for all the info :)

[ryanfleury]

No worries, glad I could help!