Re: Debugging threaded processes

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B