I've been finding egdb and gdb rather easily get stuck in an uninterruptible wait, e.g. when running the 'next' command after hitting a breakpoint.
So it's not possible to kill the debuggee or gdb and the only way to kill the debuggee process and free up its listening sockets seems to be to reboot the entire system. Perhaps unsurprisingly one cannot attach a second invocation of gdb to the uninterruptible gdb, so i don't know for sure what syscall is being run that is getting stuck. The debuggee is a local build of the flightgear flight simulator. Here's the output of ps for the debugger and debuggee: 12419 p0 D 0:34.37 egdb -ex handle SIGPIPE noprint nostop -ex set print thread-events off -ex set print pretty on -ex run --args build-walk/fgfs,clang,debug,opt,co 63921 p0 TX+ 0:42.45 /home/jules/flightgear/build-walk/fgfs,clang,debug,opt,compositor,osg.exe --airport=egtk (fgfs,clang,debug) I've tried using ktrace on egdb, and the kdump output ends like this: 53950 egdb CALL wait4(WAIT_ANY,0x7f7ffffe8efc,0<>,0) 53950 egdb RET wait4 97562/0x17d1a 53950 egdb CALL ptrace(PT_GET_PROCESS_STATE,97562,0x7f7ffffe8ef0,12) 53950 egdb RET ptrace 0 53950 egdb CALL ptrace(PT_GETREGS,161560,0x7f7ffffe8b40,0) 53950 egdb RET ptrace 0 53950 egdb CALL futex(0x6444e37c490,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 53950 egdb RET futex 0 53950 egdb CALL futex(0x644bef12740,0x82<FUTEX_WAKE|FUTEX_PRIVATE_FLAG>,1,0,0) 53950 egdb RET futex 0 53950 egdb CALL ptrace(PT_IO,97562,0x7f7ffffe8a30,0) 53950 egdb RET ptrace 0 53950 egdb CALL ptrace(PT_IO,97562,0x7f7ffffe8a30,0) 53950 egdb RET ptrace 0 53950 egdb CALL ptrace(PT_STEP,97562,0x1,0) 53950 egdb RET ptrace 0 53950 egdb CALL read(6,0x7f7ffffe9187,0x1) 53950 egdb RET read -1 errno 35 Resource temporarily unavailable 53950 egdb CALL poll(0x6441581e720,3,0) 53950 egdb STRU struct pollfd [3] { fd=4, events=0x1<POLLIN>, revents=0<> } { fd=6, events=0x1<POLLIN>, revents=0<> } { fd=10, events=0x1<POLLIN>, revents=0<> } 53950 egdb RET poll 0 53950 egdb CALL wait4(WAIT_ANY,0x7f7ffffe8efc,0<>,0) Assuming that this is the actual end of the ktrace output and there isn't some missing ktrace output in a buffer somewhere, this looks like egdb is simply blocked in wait4(), which should be harmless and certainly not uninterruptable? Does anyone have any suggestions about how to investigate this further? I'm running OpenBSD 6.7 GENERIC.MP#182 amd64. Thanks, - Jules -- http://op59.net