This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Need opinions - print-threads.exp and a wicked threads problem


I'll look at this some more later or tomorrow, but I'd like to get reactions
from anyone who has one, first.

The intermittent (reasonably frequent here) failure that I see in
print-threads.exp is caused by td_ta_map_id2thr_p returning TD_NOTHR (no
such thread).  This happens after:
  - We wait for the inferior and get an LWP
  - We map the LWP to a thread
  - That thread's state is TD_THR_ZOMBIE

This can happen pretty easily.  Look at the LinuxThreads source; once a
thread sets p_terminated, it is considered a zombie.  Then it goes on to do
a few other things before exiting.  If we stop while it's in there...
well... we have a problem.  There's a lot of things LinuxThreads won't let
us do with a zombie thread, two in particular:
  - map its TID back to a particular LWP
  - fetch its registers

I don't even want to think about what happens if this thread has hit a
breakpoint (some stupid user trying to debug LinuxThreads - like, say, me). 
Let's ignore that for the moment.  What can we do with this thread?  Not
very much, it turns out!

We stopped for a reason, so we can't just resume and look for another event;
we'd lose the reason.  In the case of print-threads.exp, the reason is the
user hitting Control-C, if I remember correctly.  We can't tell GDB that
this thread stopped; it tries to do various things to it, like read_pc(). 
The thread has become, basically, an untouchable black box.

I don't know what the right thing to do is in this situation.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]