0

When I was googling my gdb and sigwait issue, I found this kernel bug thread

GDB is not trapping SIGINT. Ctrl+C terminates program when should break gdb.

Quote:

gdb puts the debugged process in its own pgrp and sets the terminal to that pgrp.

When you hit C-c, the signal goes to the current pgrp, i.e. to the debugged process and not to gdb. When a signal is delivered, ptrace will intercept it and let gdb decide what to do before it actually reaches the debugged process.

However, your program uses sigwait and so the signal is never actually delivered. Instead, you dequeue it via sigwait without going through actual signal delivery. ptrace only reports a signal that is about to be delivered. When you use sigwait, technically the signal is blocked the whole time and never delivered as such.

This comment got me more curious about how signal and GDB actually works,

1) What is the difference between "signal delivered" and "signal queued"?

2) How does GDB trap signals while the signal is sent to the debugged process?

Thanks,

wei
  • 6,629
  • 7
  • 40
  • 52
  • I believe the distinction between "queued" and "delivered" is that whenever a signal is generated, it gets queued up on whatever target process. Whenever the process actually "gets" the signal and triggers the handler, then it's considered "delivered" – Drew McGowen Aug 11 '14 at 18:06
  • thanks, how do they differ in the case of GDB? – wei Aug 11 '14 at 21:03
  • gdb is notified (via ptrace) when the signal is delivered, not when it is queued. There's no way to detect the latter as far as I know -- hence that kernel bug. – Tom Tromey Aug 16 '14 at 01:46

0 Answers0