This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: thread id is lost when viewing list of threads in slickedit
- From: Jon Ringle <jon dot ringle at comdial dot com>
- To: SlickEdit Support <support at slickedit dot com>, gdb at sources dot redhat dot com
- Date: Fri, 23 Sep 2005 16:31:00 -0400
- Subject: Re: thread id is lost when viewing list of threads in slickedit
- References: <ECCC6E9907B4CD4A83260A191A91F20E6AC697@wampa.office.slickedit.com><200509231538.36201.jon.ringle@comdial.com><20050923195736.GA9159@nevyn.them.org>
On Friday 23 September 2005 03:57 pm, Daniel Jacobowitz wrote:
> On Fri, Sep 23, 2005 at 03:38:36PM -0400, Jon Ringle wrote:
> > CC'ing gdb mailing list this issue. It seems that via the MI interface
> > thread ID information is lost. Is there any way from the MI interface to
> > get the thread IDs that seem to be missing?
>
> The thread ID is not the third word, it's everything from the thread
> number to the thread PC. They're freeform, depending on the target, et
> cetera. So it's "thread 8201" and GDB tries to give you something
> useful.
Well, it certainly is useful when debugging a deadlock. As long as a mutex is
initialized as a recursive type, then if a deadlock occurs in an app, I can
attach to the process and look for threads that are waiting for a mutex. Then
I can find out the thread that currently owns the mutex that this thread is
waiting for by printing:
*((int*)(mutex.__m_owner) + 4)
This seems to work at least with linuxthreads.
> If you upgrade to NPTL, you'll find they get a lot less
> intelligible.
As long as they are unique and I can track them somehow in code, then it
doesn't matter too much to me.