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

Created on 19 Jul 2020  路  4Comments  路  Source: microsoft/vscode-cpptools

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",
        },
     ]
}
  1. 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"
        },
    ]
  1. 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;
}

image

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;
}

image

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;
}

image

  1. launch debugger
    Full log for example A
    log.txt
    cpu usage when hanging
    image
debugger investigate

Most helpful comment

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

All 4 comments

@zeeepw Thanks for the very detailed issue.

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

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

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.

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.

Was this page helpful?
0 / 5 - 0 ratings