lldb-mi lldb-mi hangs on M1 macOS when creating variable

lldb-mi hangs on M1 macOS when creating variable

Open LimingFang opened this issue 2 years ago • 14 comments

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:

Clone leveldb and add main.cpp
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.

microsoft/vscode-cpptools#9488

Jun 23 '22 05:06 LimingFang

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:

https://github.com/microsoft/vscode-cpptools/issues/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: Screenshot 2022-09-02 at 9 26 03

Sep 02 '22 06:09 H-G-Hristov

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

Screenshot 2022-09-02 at 9 28 12

Sep 02 '22 06:09 H-G-Hristov

After several runs I have multiple lldb-mi instances:

Screenshot 2022-09-02 at 9 29 58

Sep 02 '22 06:09 H-G-Hristov

Same here: https://github.com/lldb-tools/lldb-mi/issues/96 https://github.com/lldb-tools/lldb-mi/issues/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.

Sep 09 '22 07:09 H-G-Hristov

Nov 22 '22 20:11 hackroid

Same issue here.

Dec 13 '22 20:12 donangel

Any chance of this being looked at?

Apr 05 '23 04:04 alexolog

Is this perhaps related to https://github.com/microsoft/vscode-cpptools/issues/7240#issuecomment-997954449? @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.