Symbol is interpreted when howevering, but not within variable-explorer

[HpLightcorner]

Hi,
I am working on automating debugging with OMNeT++ CMake and VS-Code on Windows and came across a strange behaviour when debugging a simple example. The variable is successfully interpreted when hovering, but in the variable explorer only the pointer address is shown (I would expect to be able to unfold the object/pointer and interpret its content like with GDB).

Have I overseen some settings? Here the link to the issue in OMNeT++ CMake.

Here an overview of the actual launch.json

{
    "name": "Launch minimal - CodeLLDB (OMNeT++)",
    "type": "lldb",
    "request": "launch",
     "program": "path/to/opp_run_dbg.exe",
     "args": [
            "-n",
            "path/to/tests/example/",
            "-l",
            "path/to/build/libminimal.dll",
            "path/to/example/omnetpp.ini"
    ],
    "stopOnEntry": false,
    "cwd": "path/to/project/root",
    "initCommands": [
         "command script import path/to/python/omnetpp/lldb/formatters/omnetpp.py"
     ]
}

Not sure if this is a bug or a missing setting... Looking forward to getting some help!

[HpLightcorner]

Just self-answering the question: It seems that I was missing compiler flags, so that debug symbols have been missing. I would like to mention the following article and show my CMake-flags, and my configure.user file (for compiling OMNeT++) to create necessary symbols: CFLAGS_DEBUG='-glldb -fstandalone-debug' for configure.user and set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fuse-ld=lld -glldb -fstandalone-debug") for the CMake-File (on Windows).

Looking forward to any additional input - getting LLDB right is just a novel topic for me.

[HpLightcorner]

However, every now and then, debugging fails with the following stack backtrace:

[2021-07-02T10:52:51.042Z DEBUG codelldb::dap_codec] <-- {"type":"response","request_seq":14,"success":true,"command":"variables","body":{"variables":[{"evaluateName":"this","name":"this","type":"Txc *","value":"{...}","variablesReference":1006},{"evaluateName":"msg","name":"msg","type":"omnetpp::cMessage *","value":"tictocMsg @0.1s pri:0 kind:0","variablesReference":1007}]}}
[2021-07-02T10:52:51.050Z DEBUG codelldb::disassembly] Qt5Core.dll`QMimeType::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 33847
thread '<unnamed>' panicked at 'assertion failed: addr.is_valid()', adapter\src\disassembly.rs:53:9
stack backtrace:
   0:     0x7ffb2141795e - entry
   1:     0x7ffb2142e62b - rust_eh_personality
   2:     0x7ffb21412808 - entry
   3:     0x7ffb2141a6ed - entry
   4:     0x7ffb2141a1b9 - entry
   5:     0x7ffb2141afa0 - entry
   6:     0x7ffb2141aaa3 - entry
   7:     0x7ffb214182ef - entry
   8:     0x7ffb2141aa29 - entry
   9:     0x7ffb2142c160 - rust_eh_personality
  10:     0x7ffb2142c0ac - rust_eh_personality
  11:     0x7ffb2130edd5 - <unknown>
  12:     0x7ffb212cfa1a - <unknown>
  13:     0x7ffb212b6a26 - <unknown>
  14:     0x7ffb2126b006 - <unknown>
  15:     0x7ffb21268bfb - <unknown>
  16:     0x7ffb21273b4f - <unknown>
  17:     0x7ffb2131c7d2 - entry
  18:     0x7ffb212fb7b4 - <unknown>
  19:     0x7ffb21310edc - entry
  20:     0x7ff6079f4df9 - <unknown>
  21:     0x7ff6079f1a66 - <unknown>
  22:     0x7ff6079f1a90 - <unknown>
  23:     0x7ff607aebe17 - <unknown>
  24:     0x7ff6079f5507 - <unknown>
  25:     0x7ff607b0051c - <unknown>
  26:     0x7ffb92167034 - BaseThreadInitThunk
  27:     0x7ffb922a2651 - RtlUserThreadStart

Are there still symbols missing or could this be an actual bug?

[vadimcn]

Are there still symbols missing or could this be an actual bug?

Looks like you are hitting an assert caused by trying to disassemble an "invalid" address (most likely an unmapped address range). This is not supposed to happen, but you know how that usually goes... :)
So yeah, please open a bug. Would be best if you could provide a repro, otherwise I can't really investigate.