Re: expected behavior when a signal is sent to the ptraced child

Wu Zhou
2006-05-25T04:16:14Z

Hi Daniel,

On Wed, 24 May 2006, Daniel Jacobowitz wrote:

> On Thu, May 25, 2006 at 10:36:37AM +0800, Wu Zhou wrote:
> > It will stop instead. then the wait function of the prarent (in our case,
> > GDB) will return and get the control. It can inspect the status of the
> > child and know what cause the child to stop. Then gdb can let the child
> > continue using PTRACE_CONT, in this it can choose to delieve the signal on
> > to the child, and also ignore it, and even deliver a different signal.
>
> Yes.

Thanks for the confirmation.

>
> > If my understanding is correct. Then a follow up question is how to make
> > the child not to call its signal handler and to stop instead. The reason
> > I ask this is that with one kernel, I get different result than the above
> > with the following test code:
>
> If the child receives a signal, it will stop. It looks to me as if
> your kernel is not generating the signal in the normal way, i.e.
> somehow bypassing normal delivery.

In this testcase, the child enters into the signal handler and then it
continues its execution until its end. The parent get the control then.

I guess you are right, the kernel guy I am working with might use a
non-normal way to generate the signal. I need to confirm with him about
that though.

Thanks for your quick answer!
- Wu Zhou