lldb-dap windows crashes when a variable is requested

[ChristianHeinigk]

Hi all,

when running lldb-dap.exe under Windows in neovim using the nvim-dap plugin, lldb-dap.exe crashes after a frame's variables are getting requested. Not sure how to test it without neovim and nvim-dap, so it might be a problem related to my setup. I've tested with llvm from main and the latest tagged version, i.e. llvmorg-19.1.7. In addition, I've tested serving through stdout and a tcp port. Unfortunately, I can't share the project's source nor executable as I'm debugging a commercial software.

Please, find the logs attached.

lldb-dap.log

[vogelsgesang]

Does debugging the same program under lldb (outside of lldb-dap and neovim) work? Can you inspect the variables inside lldb without lldb crashing?

[ChristianHeinigk]

Yes, that works. I can successfully attach to the process, set breakpoints, and inspect variables. I can do so running lldb.exe inside Powershell, MSYS2 Bash, and inside neovim.

[ChristianHeinigk]

And it works, independently of the native PDB reader.

[heixxxa]

I found that the integratedTerminal and externalTerminal of the console have the same issue.

[ChristianHeinigk]

The culprit is triggered in JSONUtils.cpp in the function CreateVariable when the given SBValue is synthetic. The call to GetChildAtIndex(0) then results in a nullptr dereference in the underlying ValueObject pointer.

Edit: The actual dereference is here:

LibStdcppSharedPtrSyntheticFrontEnd::GetChildAtIndex(uint32_t idx) {
if(idx==0)
return m_ptr_obj->GetSP(); // <-- m_ptr_obj is nullptr!

[ChristianHeinigk]

Wrapping the if statement in a

if (v.IsSyntheticChildrenGenerated()) {
// ...
}

resolves this issue partially. But then, another nullptr dereference is triggered in GetNonNullVariableName deep inside the call to v.GetName().