> What's happening is that the signal code (5) is written into p_xstat, > and then the LWP is stopped.
> Unfortunately, p_xstat is also used to carry a signal delivered from > GDB to the process (as the fourth argument of ptrace() P_CONTINUE > function). > So what happens, if I correctly interpreted my debug sessions, is > that one thread hits the breakpoint, sets p_xstat to 5, calls > sigswitch() to get some other LWP scheduled. However, the LWP that's > picked is one of the other threads for the same process. It's > continuing from a break, so it calls sigchecktrace() to see if gdb > gave it a signal. [...] It seems to me that the basic problem here is that the kernel is trying to use a single variable - p_xstat - to carry more information than a single variable can carry; I suspect there are plenty of other cases where two things can collide over it. Consider thread A stopping, then thread B stopping before anyone has a chance to look at p_xstat from thread A. It seems to me a separate p_xstat needs to exist for each thread, which your description seems to imply is not the case. Mind you, I haven't read the code; this is based on what I read into your description, nothing more. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
