strange signal on new clone creation under ptrace?

[Tom Horsley]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/