lkml.org 
[lkml]   [2005]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subjectstrange signal on new clone creation under ptrace?
From
Date
I'm seeing this on a redhat enterprise 4 system (so the kernel is
older than dirt in lkml time :-), but I wondered if it might
strike a familiar note to anyone working on ptrace issues.

In my debugger, I'm following clone and fork creation around
to debug children using PTRACE_SETOPTIONS. Normally when I get
the waitpid() status for a new clone, it shows up with SIGSTOP
as the initial reported signal. My debugger is expecting this
and handles it no problem.

In a hairy complex threads program a user has (which is apparently
using SIGUSR1 a lot), the very first status that ever shows up for
a brand new clone reports SIGUSR1 rather than SIGSTOP.

When I teach the debugger to deal with that and get the new clone
started up, it immediately gets the SIGSTOP I didn't get on the
initial status.

I haven't been able to create any test program to reproduce this
behavior, so I have no idea how it could happen, but it appears
as though the kernel managed to queue up the signals in the wrong
order.

Does this sound like a bug anyone remembers fixing? Does anyone
have an idea how I could make it happen? Just curious about what
the heck could be going on here (I can probably teach the debugger
to work around this as well).

-
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: 2005-09-08 14:01    [W:0.027 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site