code-debug
code-debug copied to clipboard
LLDB attach hangs
If submitting a bug please make sure
- [ ] If you are using lldb
- [x]
lldb --version>= 3.7.1 - [ ] it works on the command line with
lldb-mi - [ ]
cwdandtargetare properly set
- [x]
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.
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.
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.