lldb-mi hangs on M1 macOS when creating variable

[LimingFang]

Environment

• OS and version: macOS Monterey 12.4
• VS Code: 1.68.0
• C/C++ extension: 1.11.0
• OS and version of remote machine (if applicable): no
• GDB / LLDB version: 13.0.1

Bug Summary and Steps to Reproduce

Bug Summary: When debugging some code(for example, leveldb test code), sometimes the debug can't go on.

Steps to reproduce:

1. Clone leveldb and add main.cpp

4. Debug this executable, when entering DB::Open:

then I was stuck in `*dbptr = nullptr;` where there's 4 lldb-mi process and in the right panel(variable),there is a circle spinning.

Debugger Configurations

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "cppdbg",
      "request": "launch",
      "name": "Debug main test",
      "program": "${workspaceFolder}/build/main_test",
      "args": [],
      "MIMode": "lldb",
      "cwd": "${workspaceFolder}",
      "MIMode": "lldb",
      "miDebuggerPath": "/Users/fangliming/Documents/GitHub/collections/lldb-mi/src/lldb-mi",
    }
  ]

lldb-mi version

Debugger Logs

log link

Additional Information

• lldb-mi won't exit when stop debugging.
• CodeLLDB extension works fine on my Mac.

outro

From the logs, it looks like the debugger is hanging on creating the variable edit.

-1034-var-create - - "edit" --thread 1 --frame 0

Why it is hanging on creating the VersionEdit edit variable.

• stuck when debugging c++ program on M1 Mac(Monterey) microsoft/vscode-cpptools#9488

[H-G-Hristov]

I seem to have the same issue when I try to debug a Google Test UnitTest with the TestMate C++ extension.

There are more details here:

microsoft/vscode-cpptools#9831

I hit the issue with a code like this. In this context it is reproducible 100%. In other context there is no issue.

    struct KeepAlive
    {
        /**
         * @brief `KeepAlive` subkeys.
         *
         */
        enum class Subkey
        {
            /// Subkey `AfterInitialDemand` - delaying the start.
            AfterInitialDemand,
            /// Subkey `Crashed` - depending on crashes.
            Crashed,
            /// Subkey `NetworkState` - depending on network availability.
            NetworkState,
            /// Subkey `OtherJobEnabled` - depending on other jobs.
            OtherJobEnabled,
            /// Subkey `PathState` - depending on the existence of a path.
            PathState,
            /// Subkey `SuccessfulExit` - depending on the last exit status.
            SuccessfulExit,
        };

        /**
         * @brief `KeepAlive` subkey value types.
         *
         */
        struct SubkeyValueType
        {
            /// Subkey `AfterInitialDemand` - delaying the start.
            using AfterInitialDemand = std::map<std::string, bool>;
            /// Subkey `Crashed` - depending on crashes.
            using Crashed = bool;
            /// Subkey `NetworkState` - depending on network availability.
            using NetworkState = bool;
            /// Subkey `OtherJobEnabled` - depending on other jobs.
            using OtherJobEnabled = std::map<std::string, bool>;
            /// Subkey `PathState` - depending on the existence of a path.
            using PathState = std::map<std::string, bool>;
            /// Subkey `SuccessfulExit` - depending on the last exit status.
            using SuccessfulExit = bool;
        };

        /**
         * @brief A `variant` of `KeepAlive` subkey value types.
         *
         */
        using SubkeyType = ::boost::variant2::variant<
            KeepAlive::SubkeyValueType::AfterInitialDemand,
            KeepAlive::SubkeyValueType::Crashed,
            KeepAlive::SubkeyValueType::NetworkState,
            KeepAlive::SubkeyValueType::OtherJobEnabled,
            KeepAlive::SubkeyValueType::PathState,
            KeepAlive::SubkeyValueType::SuccessfulExit>;
    };

tl::optional<
    ::boost::variant2::variant<bool, std::map<ILaunchdPlist::KeepAlive::Subkey, ILaunchdPlist::KeepAlive::SubkeyType>>>
LaunchdPlist::GetKeepAlive() const noexcept
{
...
}

TEST_F(LaunchdPlistTest, GetKeepAliveBool)
{
    // Binary plist

    auto valueOpt = LaunchdPlistTest::GetValidBinaryPlist()->GetKeepAlive();
    EXPECT_TRUE(valueOpt.has_value());

Here it hangs:

[H-G-Hristov]

If I stop debugging the lldb-mi process stays running at 100% CPU.

[H-G-Hristov]

After several runs I have multiple lldb-mi instances:

[H-G-Hristov]

Same here:
#96 #89
VSCode is rendered useless because of this in a complex scenario of C++ templates, abstract classes and Google Test.

I can confirm now that this issue happened to me on Intel macOS BigSur but it is very, very common and reproducible on M1 in the above scenario.

[hackroid]

related microsoft/vscode-cpptools/issues/10176

[donangel]

Same issue here.

[alexolog]

Any chance of this being looked at?

[garfieldnate]

Is this perhaps related to microsoft/vscode-cpptools#7240 (comment)? @shiretu posted his workaround there. Further comment:

This is truly a problem with the lldb. See my patch above. lldb is out-of-bounds-ing on walking uninitialized variables with garbage values on things like internal counters and sizes. My quick yet brutal fix is to limit these things to 64.

Unfortunately, VSCode tries to render all local variables in the current scope. And when it reaches one of those not-yet-initialized vars, it behaves like that.

[pangdaxing23]

I can confirm this is also happening on Monterey on Intel Mac.

[sunshaoce]

We need a programmer to solve this bug : )

[H-G-Hristov]

@sunshaoce This is getting a major issue. CodeLLDB also stopped working recently.

[sunshaoce]

microsoft/vscode-cpptools#7240
Here seems to be a feasible solution, can any Mac users help test it out?

[Ningen-jpg]

Same thing to me after this much time, on vs code

[sunshaoce]

Did you build the latest lldb-mi (a6c8c66)?