lkml.org 
[lkml]   [2006]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-12-19 19:03    [W:0.031 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site