svaante / dape

Debug Adapter Protocol for Emacs
GNU General Public License v3.0
455 stars 25 forks source link

dape freezes on lldb-mi (ubuntu 20.04) #145

Open vibrys opened 2 weeks ago

vibrys commented 2 weeks ago

The freeze is dependent on the break-point location. This also means I can reproduce it.

When it happens, I receive following message from dape:

Command variables timed out after 10 seconds, the timeout period is configurable with ‘dape-request-timeout' *

changing dape--timeout-error to larger value does not help.

last lines of dape-connection events (dape-debug is t of course) look like following:

[jsonrpc] e[21:17:10.024] --> variables[11] {"type":"request","seq":11,"command":"variables","arguments":{"variablesReference":1000}}
[jsonrpc] e[21:17:20.024] [11] timed-out request 'variables'

software versions used:

emacs: 29.4
dape (master): 20240825.142412
cpptools: 1.21.6
llvm: 17.0.6
lldb-mi: built from SHA1: a6c8c66
lldb-mi version:
Version: GNU gdb (GDB) 7.4
(This is a MI stub on top of LLDB and not GDB)
All rights reserved.

more debugging:

freeze looks to be infinite (it was spinning around for an hour after I've killed this). During freeze, relevant processes look like following:

         tree    CPU
vbr 8915 3       4.5 0.2 16:34 00:01 /home/vbr/.emacs.d/debug-adapters/cpptools/extension/debugAdapters/bin/OpenDebugADT
vbr 5929 3       0.6 0.0 15:16 00:00 bin/bash --noediting -i
vbr 8930 3       0.0 0.0 16:34 00:00 /bin/sh /tmp/Microsoft-MIEngine-Cmd-podoihxS.ewn
vbr 8932  4    119.5 3.9 16:34 00:29 /usr/local/bin/lldb-mi --interpreter=mi --tty=/dev/pts/3                                   <-- THIS ONE
vbr 8948   5     0.0 0.2 16:34 60:00 /usr/local/bin/lldb-server gdbserver --fd=5 --native-regs --setsid
vbr 8955    6    0.0 0.1 16:34 06:00 /home/vbr/git/gpo/Build.Debug-Branchl/bin/x64/Debug/ss -m left.yaml -i /home/vbr/Cases/C1/in.bin -d HW -r /home/vbr/Cases/C1/ref.bin

process 8932 has 18 threads, all of them are in this state (/proc/PID/stack):

[<0>] futex_wait_queue_me+0xa8/0x110
[<0>] futex_wait+0x105/0x260
[<0>] do_futex+0x1ba/0x880
[<0>] __x64_sys_futex+0x7b/0x1c0
[<0>] x64_sys_call+0x1022/0x1fa0
[<0>] do_syscall_64+0x54/0xb0
[<0>] entry_SYSCALL_64_after_hwframe+0x67/0xD1

strace -vyts 10000 -fp 8932 confirms all the threads spin around the futex call.

I've also enabled logging on cpptools. Here's the tail:

....
....
1: (2823) ->(gdb)
1: (2823) 1021: elapsed time 1
1: (2823) <-1022-var-create - - "lock" --thread 1 --frame 0
1: (2824) ->1022^done,name="var4",numchild="1",value="{...}",type="std::lock_guard<std::mutex>",thread-id="1",has_more="0"
1: (2824) ->(gdb)
1: (2824) 1022: elapsed time 1
1: (2824) <-1023-var-create - - "desc" --thread 1 --frame 0
  Command variables timed out after 10 seconds, the timeout period is configurable with ‘dape-request-timeout' *

Still not sure if it's dape issue, or rather lldb-mi/cpptools one. I'm stuck.

svaante commented 1 week ago

Hi would you mind posting the full contents of the *dape-connection events* buffer?