LLDB debugger hangs (using 100% cpu) at launch if std::map is uninitialised

[zwangz]

Type: Debugger

Describe the bug

• OS and Version: macOS 10.14.6 (Darwin x64 18.7.0)
• VS Code Version: 1.47.2
• C/C++ Extension Version: 0.29.0
• Issue:

Similar log to #860
When using include <map>and std::map/std::multimap without initialisation the debugger hangs at launch and is stuck at -var-create - - "map_variable_name" --thread 1 --frame 0; seems like no garbage value can be created
See example A below

However this does not happen, if before the (one) std::map declaration there is another container such as std::vector
or std::unordered_map declared, even uninitialised.
See example B below

And the problem re-surfaces if more than two <map> contrainers are used.
See example C below

Therefore this seems to strangely happen only to std::map containers; a few other stl containers and std::vector alone uninitialised can launch fine and be seen in the local variables window

Please could you investigate? many thanks in advance

To Reproduce

Steps to reproduce the behavior:

1. tasks.json

{
    "version": "2.0.0",
    "tasks": [
             {
            "type": "shell",
            "label": "clang++ build active file",
            "command": "/usr/bin/clang++",
            "args": [
                "-std=c++17", 			
                "-stdlib=libc++",
                "-Wall",
                "-g",
                "${fileDirname}/**.cpp",
                "-o",
		"${fileBasenameNoExtension}",
            ],
	    "options": {"cwd": "${fileDirname}"},
            "problemMatcher": ["$gcc"],
	    "group": "build",
		},
     ]
}

2. launch.json

    "version": "0.2.0",
    "configurations": [
        {
            "name": "vscpp - Build and Debug active file",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "lldb",
            "preLaunchTask": "clang++ build active file",
            "logging": {"engineLogging": true},
            "miDebuggerPath": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-mi"
        },
    ]

3. main.cpp using examples below:

EXAMPLE A

#include <iostream>
#include <string>
#include <map> 
#include <unordered_map>
#include <vector>

int main() {
    std::cout << "ISSUE" << std::endl;

    // std::unordered_map<int, int> unord_map;
    // std::vector<int> my_v;             // Same effect as using unordered_map

    std::map<int,int> my_map;
    // std::multimap<int, int> multi_map; // Same issue as my_map
    // std::map<int,int> my_map2;

    std::cout << "ISSUE" << std::endl;
    return 0;
}

EXAMPLE B

int main() {
    std::cout << "ISSUE" << std::endl;

    std::unordered_map<int, int> unord_map;
    // std::vector<int> my_v;             // Same effect as using unordered_map

    std::map<int,int> my_map;
    // std::multimap<int, int> multi_map; // Same issue as my_map
    // std::map<int,int> my_map2;

    std::cout << "ISSUE" << std::endl;
    return 0;
}

EXAMPLE C - stuck at multi_map

int main() {
    std::cout << "ISSUE" << std::endl;

    std::unordered_map<int, int> unord_map;
    // std::vector<int> my_v;             // Same effect as using unordered_map

    std::map<int,int> my_map;
    std::multimap<int, int> multi_map; // Same issue as my_map
    // std::map<int,int> my_map2;

    std::cout << "ISSUE" << std::endl;
    return 0;
}

4. launch debugger
   Full log for example A
   log.txt
   cpu usage when hanging
   

[WardenGnaw]

@zeeepw Thanks for the very detailed issue.

I will need to validate if this occurs in lldb with the non-MI commands.

[zwangz]

@zeeepw Thanks for the very detailed issue.

I will need to validate if this occurs in lldb with the non-MI commands.

Hello, has there been any progress pls?

[chrish42]

I'm having what looks like the same problem, on a big codebase (Apache Arrow). As soon as I get to a stack frame that contains more complex objects (that use STL collections in their implementation, the debugger freezes and does not respond to commands. Looking at things under the hood, VSCode is waiting forever on a reply to the following: 1: (18328) <-1041-var-create - - "parser" --thread 1 --frame 0 (parser is a variable that uses STL collections).

This is making C++ debugging completely unusable for me.

[bubbercn]

I've been experiencing this issue when debugging C++ program in macOS. When this happens, I have to turn to Xcode which works perfectly. So I would have to guess lldb works fine and it is a lldb-mi specific issue.

@zeeepw Thanks for the very detailed issue.

I will need to validate if this occurs in lldb with the non-MI commands.

[DominicCabral]

Can confirm this is still happening on:
OS and Version: macOS 10.15.7
VS Code Version: 1.53.2
C/C++ Extension Version: 1.2.0

[arvindx101]

HI

Is there any update on this ? I am writing a simple C++ program for maps and not able to debug at all!!

[bubbercn]

I just can not believe this issue still hasn't been addressed. I've been running into this for more than one year. And my workaround is to not use lldb-mi at all.

[Wdong04]

just ran into it. Cannot believe it is still unresolved

[n-hass]

I've got this same issue.

[josueaanyosa]

It happens to me a lot. I restart my MacBook and sometimes it fixes it. Other times it does not help at all.

[blanerhoads]

Happens to me with unordered_map, sometimes even if it's initialized.

I just need an IDE with a debugger and a CMake extension for OSX. Any workarounds or recommendations?