WebFreak001 / code-debug

Native debugging for VSCode
The Unlicense
398 stars 116 forks source link

LLDB attach hangs #196

Open tomasz-grobelny opened 4 years ago

tomasz-grobelny commented 4 years ago

If submitting a bug please make sure

I have the following configuration:

        {
            "type": "lldb-mi",
            "request": "attach",
            "name": "Attach to PID - lldb",
            "target": "11172",
            "cwd": "${workspaceRoot}",
        },

The process is already running as root (started from systemd) on remote host. cmake uses Clang 9.0. When I try to run this debug configuration it just hangs - no error whatsoever. When looking on the remote machine I see there is lldb-mi process, but that's all I can say.

I know there is not much info here therefore it would be great if you could let me know how I can debug this issue.

First, is there any logging I can enable? Now the Debug console is all empty.

Second, is there a way I can check lldb "manually" on the remote machine? I mean without vscode.

WebFreak001 commented 4 years ago

remote host? If you want to attach remotely you need to either debug over SSH (running lldb-mi on the remote system with debug binary and sources available on the remote system) or using a gdbserver (with debug binary available on the remote system), though I don't know how well that will work with lldb-mi

Run lldb manually how you would normally debug without vscode to check it on the command line.

There is "printCalls" and "showDevDebugOutput" if you want to see what the extension is doing.

tomasz-grobelny commented 4 years ago

I use remote development extension of vscode so the sources and process are remote. Here is how lldb behaves in "manual" scenario:

root@arm:/home/tomek# lldb
(lldb) attach 11568
Process 11568 stopped
* thread #1, name = 'ffs-test', stop reason = signal SIGCONT
    frame #0: 0xffffffffffffffff 
  thread #2, name = 'ffs-test', stop reason = signal SIGCONT
    frame #0: 0xffffffffffffffff 

Architecture set to: .
(lldb) bt
* thread #1, name = 'ffs-test', stop reason = signal SIGCONT
  frame #0: 0xffffffffffffffff 
(lldb) thread backtrace
* thread #1, name = 'ffs-test', stop reason = signal SIGCONT
  frame #0: 0xffffffffffffffff 

Not sure this is correct. It seems to attach but I would expect something more from a backtrace.

As for "printCalls"/"showDevDebugOutput" here is the debug console output:

1-gdb-set target-async on
GDB -> App: {"token":1,"outOfBandRecord":[],"resultRecords":{"resultClass":"done","results":[]}}

One thing that may be important here is that the remote system is arm.