views:

177

answers:

1

Hello

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().

+1  A: 

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.)

osgx
So, with SETSIGNFO/GETSIGINFO debuggers will be transparent in signal delivering.
osgx