Question

Can I distinguish signal, between delivered directly to a process and delivered via debugger.

Case 1:

 $ ./process1
 process1 (not ptraced)
 //set up handler
 alarm(5);
 ....
 //signal is handled and I can parse handler parameters

Case 2:

 $ debugger1 ./process1
 process1 (is ptraced by debugger1)
 //set up handler
 alarm(5);
 ...
 //signal is catched by debugger1. It resumes process1 with PTRACE_CONT,
 // signal_number is 4th parameter of PTRACE_CONT.
 //signal is redelivered to process1
 //and then is handled.

So, how can I detect in signal handler, was it redelivered by debugger or send by system?

OS is Linux, kernel is 2.6.30. Programs are written in plain C. In real program SIGALRM is used, but it is generated not by alarm(), but with setitimer().

Answer 1

man ptrace: ( http://linux.die.net/man/2/ptrace )

PTRACE_GETSIGINFO (since Linux
2.3.99-pre6) Retrieve information about the signal that caused the stop.
Copies a siginfo_t structure (see
sigaction(2)) from the child to
location data in the parent. (addr is
ignored.)

PTRACE_SETSIGINFO (since Linux
2.3.99-pre6) Set signal information. Copies a siginfo_t structure from
location data in the parent to the
child. This will only affect signals
that would normally be delivered to
the child and were caught by the
tracer. It may be difficult to tell
these normal signals from synthetic
signals generated by ptrace()
itself. (addr is ignored.)

PTRACE_CONT Restarts the stopped
child process. If data is non-zero and
not SIGSTOP, it is interpreted as a
signal to be delivered to the child;
otherwise, no signal is delivered.
Thus, for example, the parent can
control whether a signal sent to the
child is delivered or not. (addr is
ignored.)