llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.08k stars 11.99k forks source link

lldb doesn't pause on ctrl+C if lldb was given the '-o run' option to start execution immediately #69127

Open mortie opened 1 year ago

mortie commented 1 year ago

When I run lldb ./my-program, type run 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 with lldb -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.

llvmbot commented 1 year ago

@llvm/issue-subscribers-lldb

Author: Martin Dørum (mortie)

When I run `lldb ./my-program`, type `run` 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 with `lldb -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.
jasonmolenda commented 1 year ago

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.

jasonmolenda commented 1 year ago

I checked back releases from the past couple years, this doesn't look like a regression, it's been misbehaving for a while.