Messages in this thread | | | Date | Tue, 19 Dec 2006 12:55:06 -0500 | From | Chuck Ebbert <> | Subject | Re: problem with signal delivery SIGCHLD |
| |
In-Reply-To: <Pine.LNX.4.60.0612181924470.2560@rtl14.hofr.at>
On Mon, 18 Dec 2006 20:05:35 +0100, Nicholas Mc Guire wrote:
> I have a phenomena that I don't quite understand. gdbserver forks and > after setting ptrace (PTRACE_TRACEME, 0, 0, 0); it then execv > (program, allargs); when this child process hits ptrace_stoped (breakpoint > it does the following in kernel space: > > pid > 1 559 5 1242 ptrace_stop > 3 6 2 1242 | do_notify_parent_cldstop > 4 3 2 1242 | | __group_send_sig_info > 5 1 1 1242 | | | handle_stop_signal > 7 0 0 1242 | | | sig_ignored > 8 1 0 1242 | | __wake_up_sync > 8 1 1 1242 | | | __wake_up_common > 10 547 541 1242 | schedule > 10 2 2 1242 | | profile_hit > 13 1 1 1242 | | sched_clock > 15 1 0 1242 | | deactivate_task > 15 1 1 1242 | | | dequeue_task > 19 2 2 0 | | __switch_to
> 24 574 574 0 default_idle
> So basically child signals -> delayed to next tick -> parent wakes up.
What do the first three columns represent?
Do you see __wake_up_common() calling default_wake_function()?
Can you trace through schedule() and see exactly how it decides to run the idle task instead of the newly-woken parent? Exactly what path does it take? (And which kernel version is this?)
-- MBTI: IXTP
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |