Messages in this thread | | | Subject | strange signal on new clone creation under ptrace? | From | Tom Horsley <> | Date | Thu, 08 Sep 2005 07:53:38 -0400 |
| |
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/
| |