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

[conversy]

Environment

• OS and version: MacOS 12.4
• VS Code: 1.70.2 (Universal) Commit: e4503b30fc78200f846c62cf8091b76ff5547662
• C/C++ extension: v1.12.1
• OS and version of remote machine (if applicable):
• GDB / LLDB version: lldb-1316.0.9.46

Bug Summary and Steps to Reproduce

Bug Summary:

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.

Steps to reproduce:

1. In this environment...
2. With this config...
3. Do '...'
4. See error...

Debugger Configurations

tasks.json:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "test",
            "type": "shell",
            "command": "make -j test"
        },
        {
[...]

launch.json:
"version": "0.2.0",
    "configurations": [

        {
            "name": "(lldb) Lancer",
            //"type": "cppdbg",
            //"type": "lldb-vscode",
            "type": "lldb",
            "request": "launch",
            "program": "${workspaceFolder}/build/cohoma",
            "cwd": "${workspaceFolder}",
            "args": ["\"\""],

            "env":
                {
                    "DYLD_LIBRARY_PATH":"${DYLD_LIBRARY_PATH}:${workspaceFolder}/../djnn-cpp-opengl/build/lib:${workspaceFolder}/../smala/build/lib/",//:/Users/conversy/recherche/istar/code/misc/MGL/build",
                },

Debugger Logs

(in French, but should be understandable)

[8/24/2022, 2:22:19 PM] Pour les fichiers sources C++, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:19 PM] Pour les fichiers sources C, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:19 PM] Pour les fichiers sources C++, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:19 PM] Pour les fichiers sources C, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:24 PM] Pour les fichiers sources C++, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:24 PM] Pour les fichiers sources C, IntelliSenseMode est passé de "macos-clang-x64" à "macos-clang-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/usr/bin/clang"
[8/24/2022, 2:22:24 PM] Pour les fichiers sources C++, IntelliSenseMode est passé de "macos-clang-x64" à "macos-gcc-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/opt/homebrew/bin/gcc-11"
[8/24/2022, 2:22:24 PM] IntelliSenseMode a été modifié car il ne correspondait pas au compilateur détecté.  Envisagez de définir "compilerPath" à la place.  Définissez "compilerPath" à "" pour désactiver la détection des includes et defines du système.
[8/24/2022, 2:22:24 PM] Pour les fichiers sources C, IntelliSenseMode est passé de "macos-clang-x64" à "macos-gcc-arm64" en fonction des arguments du compilateur et de l'interrogation de compilerPath : "/opt/homebrew/bin/gcc-11"
[8/24/2022, 2:22:24 PM] IntelliSenseMode a été modifié car il ne correspondait pas au compilateur détecté.  Envisagez de définir "compilerPath" à la place.  Définissez "compilerPath" à "" pour désactiver la détection des includes et defines du système.

Other Extensions

No response

Additional Information

[WardenGnaw]

Looks like self is not being visualized correctly.

The logs you provided are for the language service, can you provide the debugger logs when you add the following to your launch.json?

"logging": {
   "engineLogging": true,
   "traceResponse": true
}

And share the logs from the Debug Console.

[conversy]

Debug Console is empty. Here is the content of launch.json, is it correct?

{ // Use IntelliSense to learn about possible attributes. // Hover to view descriptions of existing attributes. // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387

"version": "0.2.0",
"configurations": [
    {
        "name": "(lldb) Lancer",
        "type": "lldb",
        "request": "launch",
        "program": "${workspaceFolder}/build/cohoma",
        "cwd": "${workspaceFolder}",
        "args": ["\"\""],

        "env":
            {
                "DYLD_LIBRARY_PATH":"${DYLD_LIBRARY_PATH}:${workspaceFolder}/../djnn-cpp-opengl/build/lib:${workspaceFolder}/../smala/build/lib/",//:/Users/conversy/recherche/istar/code/misc/MGL/build",
            }
    }
],
"logging": {
    "trace": true,
    "traceResponse": true,
    "engineLogging": true
}

}

[WardenGnaw]

Oh sorry, I did not realize you commented out "type": "cppdbg".

You will want to go to https://github.com/vadimcn/vscode-lldb/issues for issues with "type": "lldb".

[conversy]

thanks, so I need to open a new issue over there, right?

[WardenGnaw]

thanks, so I need to open a new issue over there, right?

Yep. As it is in another organization, we are unable to move this issue over there. You will need to create a new issue.