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?

[remyers]

Can confirm this is still happening on:
OS and Version: macOS 11.6
VS Code Version: 1.62.0
C/C++ Extension Version: 1.7.1

When I uncomment the declaration of multi_map (example C) and set a breakpoint on the first line of main() or have "stopAtEntry": true then lldb-mi goes to high CPU and I have to kill it and the debugged process manually.

I could also reproduce the high cpu hang without a breakpoint on the first line of main() if I attached to the process and put the code in a function called after a sleep with a breakpoint at the start of the function.

[ScherbakovAl]

I also ran into a similar issue.

[TwentyPast4]

Same here

[csloan-gmail]

I have a similar problem and I noticed the local section in the variables window in the Visual Code debugger has a spinner during the hang. I hid the variables window and the debugger no longer hangs. Hopefully this works for someone else because this was driving me insane.

[nazavode]

I have a similar problem and I noticed the local section in the variables window in the Visual Code debugger has a spinner during the hang. I hid the variables window and the debugger no longer hangs. Hopefully this works for someone else because this was driving me insane.

@csloan-gmail It works, thanks. Not a solution but this allows to actually debug stuff, at least.

[sebrockm]

@csloan-gmail Thanks! That works for me if in addition I'm also super careful with my mouse to not accidentally hover over a map.

[filipecustodio]

Thanks @csloan-gmail same problem here. Workaround (not looking at variables) at least allows me to move forward.

[eliyaoo32]

I have a similar problem and I noticed the local section in the variables window in the Visual Code debugger has a spinner during the hang. I hid the variables window and the debugger no longer hangs. Hopefully this works for someone else because this was driving me insane.

Thanks, it solved the issues.
I hope it will be fixed soon.

[basdp]

Have the same problem on MacOS, hiding variable window is a partial workaround for now.

[filipecustodio]

I have the same experience both on LLDB and on Perl Debugger, using VSCode on Mac, so maybe the problem is not in LLDB but in VSCode? Cheers FC

…

On 13 Jan 2023, at 12:19, Bas du Pré ***@***.***> wrote: Have the same problem on MacOS, hiding variable window is a partial workaround for now. — Reply to this email directly, view it on GitHub <#5805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIAC4OXZV7VOQR65BCZPUPDWSFB4FANCNFSM4PBTBPLA>. You are receiving this because you commented.

[alexolog]

The CodeLLDB extension works without hanging (or hogging the CPU, or using all the memory) on Apple M1 with the variables window open, so it can be done.
https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb

[github-actions]

This issue has been closed as lower priority. We're sorry if this issue still impacts you but unfortunately we're not able to address this. We will accept a pull request from the community if it's applicable for this issue.

[gojzdar]

Same here. I can't debug at all if my HandleMouseEvent(SDL_mouse) ) is in the call stack. Works perfectly fine everywhere else.

Using Kubuntu 23.04, CodeLLDB

[javabr]

this is still happening!

[finnwang1984]

this is still happening!