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

[alexolog]

Any chance of this being looked at?

[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:

[hackroid]

related microsoft/vscode-cpptools/issues/10176

[donangel]

Same issue here.

[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]

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.

[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?