[lldb] resolving optional crashes lldb(-dap) (clang/windows/msvc)

[BjornSAIM]

When debugging from vscode/cursor using lldb-dap. the debugger will crash when trying to resolve an std::optional. switching the std::optional out with an different implementation (like Optional26 by beman) fixes the problem.

link to a minimal repro: https://github.com/BjornSAIM/lldb-optional-crash
just set a breakpoint anywhere after the assignment to the optional.

clang/lldb/... are all on 19.1.1
Visual Studio 2022 version 17.9

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (BjornSAIM)

When debugging from vscode/cursor using lldb-dap. the debugger will crash when trying to resolve an std::optional. switching the std::optional out with an different implementation (like Optional26 by beman) fixes the problem.

link to a minimal repro: https://github.com/BjornSAIM/lldb-optional-crash
just set a breakpoint anywhere after the assignment to the optional.

clang/lldb/... are all on 19.1.1
Visual Studio 2022 version 17.9

[BjornSAIM]

Removing the optional related entries in CPlusPlusLanguage.cpp also fixes the problem.

[Michael137]

I assume you're using MSVC (generating PDB)? Any chance you could attach a backtrace? I'm not sure what the data-formatter story looks like on Windows. Might be wrong, but I don't think we really have formatter support for the MSVC STL. But we shouldn't crash

[BjornSAIM]

I'm using clang 19 targetting x86_64-pc-windows-msvc
I'll look into attaching a backtrace soon

[BjornSAIM]

Hi, I tracked the problem down to these lines:
GenericOptional.cpp:73 - the result of m_backend.GetChildMemberWithName("_M_payload") is not checked before dereferencing
GenericOptional.cpp:98 - a bunch of stuff derefenced without checking
GenericOptional.cpp:102 - same

[Michael137]

Thanks for the info. Could you run:

frame variable --raw <your optional variable>

To see what the optional layout is that you're dealing with. I'm surprised you would be going down the LibStdCpp formatter path on Windows. OOh it's probably because it matches the std::optional<.+>(( )?&)?$" regex (which is for libstdc++, whereas libc++ has an inline namespace).

What STL are you compiling against?

[BjornSAIM]

I'm using MSVC STL.

(std::optional<bool>) opt_val = {
  std::_Optional_construct_base<bool> = {
    std::_Optional_destruct_base<bool, 1> = {
       = {
        _Dummy = {}
         = {
          _Value = false
          _Has_value = true
        }
      }
    }
  }
}

In general, a lot of the std:: types are broken in de debugger visualisation as well because they are overriden with configurations with a layout that does not exist for my implementation. So I'm having to make custom formatters to fix that.

[Michael137]

I'm using MSVC STL.

Hmmm yea that's what I was concerned about

I don't know if we have a good story about MSVC STL data-formatter support. Though auto-detecting libstdc++ when the debuggee wasn't actually compiled against it seems bad. Though I'm not sure of good alternatives to detecting the STL without explicitly putting that info into DWARF somehow.

@ZequanWu @omjavaid @DavidSpickett Do you know what the state of debugging MSVC STL-based programs is? Is Clang+MSVC STL a supported/recommended configuration in the first place?

That being said, I also don't think we should unconditionally dereference all of those GetChildMemberWithName calls. Even if we did debug libstdc++, the layouts in libstdc++ might change without the relevant LLDB support, in which case we shouldn't crash. We're pretty good about this with the libc++ formatters, not so much with libstdc++ it seems

[BjornSAIM]

It's actually the default configuration on windows. (when using cmake, I mean)

Even simply not adding any formatters for MSVC-based configuration would already be a big improvement, because then something like lldb-dap (in vscode) will still show something remotely useful instead of garbage (std::vector only shows size = 0) or nothing (std::unique_ptr), or like in this case: crash.