CODEWITHSUNDEEP
cposixsignalskill
ayelder
ayelder

Reputation: 309

POSIX signal behavior

If a process is currently stopped due to a SIGTRAP signal and it is sent a SIGSTOP signal via kill(), what would be the default behavior? Would the SIGSTOP be a pending signal that is delivered after the process continues again? Or will it just be discarded/ignored?

If the SIGSTOP is queued up, is there any way to remove it from the queue from outside of that process, such as in a tracing process?

Upvotes: 7

Views: 1226

Answers (2)

Chris Dodd
Chris Dodd

Reputation: 126110

What do you mean 'stopped due to a SIGTRAP signal'? A SIGTRAP will not stop a process; by default it will terminate with a core dump, or you can change it to ignore the signal or call a signal handler, but in no case will the SIGTRAP stop the process by itself. You might have the process being traced by some other process (such as a debugger) with ptrace(2), in which case it will stop just before delivering the SIGTRAP, but in that case its under the control of the ptrace and won't continue until there's a PTRACE_CONT or other ptrace action to continue the process.

Upvotes: 0

Stéphane
Stéphane

Reputation: 20340

From the signal(7) man page:

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

A simple test with an app stopped on a breakpoint and sending it a SIGSTOP shows gdb displaying some information when I hit 'next'. The signal was obviously delivered to the app. It cannot continue to be debugged until I send it a SIGCONT.

(gdb) next
Program received signal SIGSTOP, Stopped (signal).
fill (arr=0x7fffffffdff0, size=5) at tmp.cpp:28
(gdb) next
Program received signal SIGCONT, Continued.
fill (arr=0x7fffffffdff0, size=5) at tmp.cpp:28
(gdb) next
(gdb)

Upvotes: 3

Related Questions