Is there any good reason why the ptrace interface needs to have visibility on
signals that would otherwise get dropped by 'ignored_signal'? This causes an
annoying divergence in signal behavior. For example, if a traced process
doing a nanosleep receives a signal that it is SIG_IGN'ing, the call gets
interrupted. This doesn't happen if it's not being traced.
There might be a certain remote logic to letting gdb/strace see attempted
delivery of ignored signals, but it doesn't get to see *blocked* signals
(until/unless they are unblocked), so this doesn't seem consistent or
particularly useful.
So, if the PF_PTRACED test got dropped from the below, would any existing
programs be harmed? There are other divergence problems, but at least this
would be a step in the right direction.
--Mike
static int ignored_signal(int sig, struct task_struct *t)
{
...
/* Don't ignore traced or blocked signals */
if ((t->flags & PF_PTRACED) || sigismember(&t->blocked, sig))
return 0;
-- Any sufficiently adverse technology is indistinguishable from Microsoft.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:14 EST