Open mortie opened 1 year ago
@llvm/issue-subscribers-lldb
Author: Martin Dørum (mortie)
In the normal debug session where run
is entered on the lldb command line, we're in the IOHandlerProcessSTDIO::Run()
loop and see the incoming interrupt and we call Process::SendAsyncInterrupt()
which sends the ^c over gdb-remote etc. But when we start the inferior with -o run
on the lldb command line, I think the process events are hijacked and the events are never processed. I don't know this part of lldb much.
I checked back releases from the past couple years, this doesn't look like a regression, it's been misbehaving for a while.
When I run
lldb ./my-program
, typerun
manually and then hit ^C, lldb will catch the SIGINT and pause execution, as if it had hit a breakpoint.When I run
lldb -o run ./my-program
to start execution immediately and then hit ^C, lldb does not pause execution, the SIGINT is just ignored.This is happening on macOS 14.0, and I have verified that it happens on both lldb-1500.0.22.8 from Apple (
/usr/bin/lldb
) and the LLDB in Homebrew's LLVM package (version 17.0.2).To reproduce, create any long-running executable (such as the C program
int main() { while (1); }
), run it withlldb -o run /path/to/executable
, and hit ^C.Interestingly, I did run
lldb -o 'log enable -v lldb all' -o 'run' ./my-program
, and with that extra logging, hitting ^C makes lldb output:[internal] void lldb::SBDebugger::DispatchInputInterrupt() (0x16f51ab50)
, so some part of LLDB is clearly aware that it should trigger an interrupt.