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

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:

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

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

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

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

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

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

HI

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

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.

just ran into it. Cannot believe it is still unresolved

I've got this same issue.

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

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?

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.

I also ran into a similar issue.

Same here

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.

Chris Sloan (@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.

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

Chris Sloan (@csloan-gmail)

Chris Sloan (@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.

Chris Sloan (@csloan-gmail)

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

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.

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

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.

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

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.

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

this is still happening!

Apple M3 Pro MacOs 15.0 [ VSCode 1.94.2 (Universal) OS: Darwin arm64 24.0.0 ]

problem still exists.

I'v founded several solutions:

as said above - hide variables and expand it when pass "bad" lines. - but it's not solution for debug - if i have in code in many places not initialized vars - while they all not passed - if I expand - I hung up.
in this variant I use external terminal and launch.json:

{
    "configurations": [
       {
            "name": "C/C++: clang++ сборка и отладка активного файла",
            "type": "cppdbg",
            "request": "launch",
            "program": "${fileDirname}/${fileBasenameNoExtension}",
            "args": [],
            "stopAtEntry": true,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "lldb",
            "preLaunchTask": "C/C++: clang++ сборка активного файла"
        }
    ],
    "version": "2.0.0"
}

second solution I'm using now is plugin CodeLLDB - with internal terminal. launch.json:

{
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Launch",
            "program": "${workspaceFolder}/${fileBasenameNoExtension}",
            "args": [],
            "cwd": "${workspaceFolder}",
            "preLaunchTask": "C/C++: clang++ сборка активного файла"
        }
    ],
    "version": "2.0.0"
}

this one best for now (but I hear that it plugin have some issues in other places.. will see)

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

WardenGnaw commented on Jul 20, 2020

zwangz commented on Jul 26, 2020

chrish42 commented on Sep 3, 2020

bubbercn commented on Nov 14, 2020

DominicCabral commented on Feb 15, 2021

arvindx101 commented on Jul 27, 2021

bubbercn commented on Aug 21, 2021

Wdong04 commented on Aug 30, 2021

n-hass commented on Oct 10, 2021

josueaanyosa commented on Oct 16, 2021

blanerhoads commented on Oct 16, 2021

remyers commented on Nov 6, 2021

ScherbakovAl commented on Feb 23, 2022

TwentyPast4 commented on Mar 1, 2022

csloan-gmail commented on Apr 19, 2022

nazavode commented on Apr 30, 2022

sebrockm commented on May 2, 2022

filipecustodio commented on Oct 17, 2022

eliyaoo32 commented on Jan 7, 2023

basdp commented on Jan 13, 2023

filipecustodio commented on Jan 13, 2023

alexolog commented on Feb 3, 2023

github-actions commented on Aug 3, 2023

gojzdar commented on Aug 19, 2023

javabr commented on Oct 31, 2023

finnwang1984 commented on Dec 5, 2023

zeves095 commented on Oct 23, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions