Missing parent classes in C++ type hierarchy in debug view

[conversy]

OS: MacOS 12.4 VSCode version: 1.71.0 (Universal)Commit: 784b0177c56c607789f9638da7b6bf3230d47a8c CodeLLDB version: v0.2.3 Compiler: clang Apple clang version 13.1.6 (clang-1316.0.21.2.5) arm64-apple-darwin21.5.0 Debuggee: lldb-1316.0.9.46

When browsing the variables in the "RUN AND DEBUG" panel, either their type does not appear (only as an hex number), or some classes are missing. In the attached screenshot, variable self appears as a number, though it should be a CoreProcess*, and the navigation into variable g is possible but stops at djnn::AbstractGObj, though djnn::AbstractGObj inherits from djnn::FatProcess.

Unfortunately it's difficult to reproduce without my (closed) source code.

Verbose log

[vadimcn]

Does this reproduce in CLI LLDB?

[conversy]

good question I'll check ASAP

[conversy]

I get this:

Process 53551 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000101553ff8 libdjnn-gui.dylib`djnn::GLWindow::update_children(this=0x0000000106547580, self=0x0000000104c2df40, force_change=0) at gl_window.cpp:644:48
   641 	
   642 	    unsigned int self_change = notify_none;
   643 	
-> 644 	    if (auto * g = dynamic_cast<AbstractGObj*>(self)) {
   645 	        auto update_next_shape_index = false;
   646 	        GLShapeImpl* impl;
   647 	        // if it's a shape...
Target 0: (simplest_app) stopped.
(lldb) p self
(djnn::GUIStructureHolder *) $0 = 0x0000000104c2df40
(lldb) p *self
(djnn::CoreProcess) $1 = {
  _vertex = nullptr
  _bitset = 24
  _debug_parent = nullptr
  _debug_name = "GUIStructureHolder_of_root"
  _dbg_info = (filepath = "/Users/conversy/recherche/istar/code/djnn/smala/cookbook/gui/direct_manipulation/simplest/simplest.sma", lineno = 23)
}

and later after a few iterations/steps:

(lldb) p g
(djnn::Rectangle *) $0 = 0x0000000104a09980
(lldb) p *g
(djnn::AbstractGObj) $1 = {
  _frame = 0x0000000106547c80
  _impl = 0x000000010592e2c0
  _gui_holder = 0x0000000104c336c0
}

Note that when the application is running in the debug mode of VS, in the Debug Console I also get:

print self
(djnn::GUIStructureHolder *) $1 = 0x0000000104c2df40

which seems to mean that lldb inside VSCode also knows that self is a GUIStructureHolder, but for some reasons VSCode does not enable one to explore it as such...

[vadimcn]

CodeLLDB version: v0.2.3

Wait, what? Are you sure you are using the codelldb extension?

[conversy]

oops sorry, it's v1.7.4. I searched for lddb in my extensions, and I picked up the version number of another, not installed, but similarly named extension.

[vadimcn]

Sorry, I don't know what's going on here. Further investigation would require a repro.

If you are so inclined, you can try to dump the object hierarchy LLDB exposes via its API (which CodeLLDB uses to render the variables view):

script var = lldb.frame.FindVariable('self')
script for i in range(var.GetNumChildren()): print(var.GetChildAtIndex(i).name) 

var will be a SBValue object (Make sure the Debug Console in in "commands" mode, or else you'll need to prefix commands with /cmd )

Normally, base class should be the first child in this list.

[conversy]

Thank you for your help, if I find a solution, I'll make a notice here.

[conversy]

Well, it seems I found the culprit. Everything seems to run fine when I turn off the use of precompiled headers... There might be some compiler switches to enable both precompiled headers and debug information, but I have not found them yet...