Does ptrace really need to see ignored signals?

From: Mike Coleman (mkc@kc.net)
Date: Tue Jan 25 2000 - 03:13:22 EST

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