Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

c++ lldb debugger seems hangs #860

Closed
haiy opened this issue Jul 3, 2017 · 5 comments
Closed

c++ lldb debugger seems hangs #860

haiy opened this issue Jul 3, 2017 · 5 comments
Labels
debugger more info needed The issue report is not actionable in its current state

Comments

@haiy
Copy link

haiy commented Jul 3, 2017

  • VSCode Version: Code 1.13.1 (379d2efb5539b09112c793d3d9a413017d736f89, 2017-06-14T18:13:05.928Z)
  • OS Version: Darwin x64 15.6.0
  • Extensions:
Extension Author Version
python donjayamanne 0.6.5
vscode-clang mitaki28 0.2.2
cpptools ms-vscode 0.12.0

Steps to Reproduce:

  1. I'm debugging tensorflow source code,at first I use bazel command
bazel run  -c opt -c dbg --strip=never //tensorflow/cc/example:example 

to compile the source normally and then I use vs to debug.My launch.json is

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/bazel-out/darwin_x86_64-dbg/bin/tensorflow/cc/example/example",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "lldb"
        }
    ]
}

at first, the debugger works fine, but when I set a breakpoint at 405 in tensorflow/core/common_runtime/direct_session.cc ,the debugger seems hangs, I can't run to next line or step out.

I've tried to debug the program with lldb in terminal with command

lldb bazel-out/darwin_x86_64-dbg/bin/tensorflow/cc/example/example

everything works normally.

@pieandcakes
Copy link
Contributor

pieandcakes commented Jul 5, 2017

@haiy we use MI command interpreter mode in lldb to talk to the debugger. You can duplicate this from the command line by using lldb-mi instead of lldb. To see what we are sending and what we get back, you can enable "logging": { "engineLogging": true }

@pieandcakes pieandcakes added the more info needed The issue report is not actionable in its current state label Oct 7, 2017
@pieandcakes
Copy link
Contributor

Please provide more information if this is still an issue and reopen.

@peteralm80
Copy link

I managed to reproduce this in a small project. The uninitialised vectors needed to be in a class with a vtable for them to have garbage data.

This the engineLogging for the problem with a breakpoint at line 24, lldb-mi seems to get stuck at var-create:

1: (850) ->*stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={level="0",addr="0x0000000100001ec6",func="main",args=[],file="lldb-hang.cpp",fullname="/Users/peter/src/lldb-hang/lldb-hang.cpp",line="24"},thread-id="1",stopped-threads="all"   
1: (850) ->(gdb)
1: (851) <-1013-thread-info 1
1: (851) <-1014-thread-info
1: (851) ->1013^done,threads=[{id="1",target-id="Thread 1",frame={level="0",addr="0x0000000100001ec6",func="main",args=[],file="lldb-hang.cpp",fullname="/Users/peter/src/lldb-hang/lldb-hang.cpp",line="24"},frame={level="1",addr="0x00007fff60c13015",func="start",args=[],file="??",fullname="??",line="-1"},state="stopped"}]
1: (851) ->(gdb)
1: (852) 1013: elapsed time 0
1: (852) ->1014^done,threads=[{id="1",target-id="Thread 1",frame={level="0",addr="0x0000000100001ec6",func="main",args=[],file="lldb-hang.cpp",fullname="/Users/peter/src/lldb-hang/lldb-hang.cpp",line="24"},frame={level="1",addr="0x00007fff60c13015",func="start",args=[],file="??",fullname="??",line="-1"},state="stopped"}],current-thread-id="1"
1: (852) ->(gdb)
1: (852) 1014: elapsed time 0
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
1: (888) <-1015-stack-list-variables 0 --thread 1 --frame 0
1: (891) ->1015^done,variables=[{name="baz"}]
1: (891) 1015: elapsed time 3
1: (891) ->(gdb)
1: (894) <-1016-var-create - - "baz" --thread 1 --frame 0

Running this in the regular lldb-cli you can see that the one of the vectors has a sizeof 2^32-1:

* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100001e96 lldb-hang`main at lldb-hang.cpp:24
   21   int main()
   22   {
   23       foo();
-> 24       std::cout << "Hello world\n";
   25       Foo baz[10];
   26   }
Target 0: (lldb-hang) stopped.
(lldb) p baz
(Foo [10]) $0 = {
  [0] = {
    vec_ = size=0 {}
  }
  [1] = {
    vec_ = size=0 {}
  }
  [2] = {
    vec_ = size=0 {}
  }
  [3] = {
    vec_ = size=0 {}
  }
  [4] = {
    vec_ = size=0 {}
  }
  [5] = {
    vec_ = size=0 {}
  }
  [6] = {
    vec_ = size=0 {}
  }
  [7] = {
    vec_ = size=4294967295 {
      [0] = 72057628379708111
      [1] = 10737418243
      [2] = 7078106103824
...

If I attach lldb to the hung lldb-mi process I can see that var-create is stuck iterating over 4 billion entries in this for loop: https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-mi/MICmdCmdVar.cpp#L300

lldb-hang.zip

@haohaolee
Copy link

The same here. lldb-mi hangs at 100% cpu and the last message is:
-var-create - - "result" --thread 1 --frame 0

@zwangz
Copy link

zwangz commented Jul 18, 2020

The same here. lldb-mi hangs at 100% cpu and the last message is:
-var-create - - "result" --thread 1 --frame 0

Same issue here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debugger more info needed The issue report is not actionable in its current state
Projects
None yet
Development

No branches or pull requests

5 participants