From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 646 invoked by alias); 23 Sep 2005 20:32:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31955 invoked by uid 22791); 23 Sep 2005 20:32:24 -0000 Received: from vms046pub.verizon.net (HELO vms046pub.verizon.net) (206.46.252.46) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 23 Sep 2005 20:32:24 +0000 Received: from [10.74.64.200] ([12.153.69.6]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0INA00CQ9EDTC922@vms046.mailsrvcs.net> for gdb@sources.redhat.com; Fri, 23 Sep 2005 15:32:17 -0500 (CDT) Date: Fri, 23 Sep 2005 20:32:00 -0000 From: Jon Ringle Subject: Re: thread id is lost when viewing list of threads in slickedit In-reply-to: <20050923195736.GA9159@nevyn.them.org> To: SlickEdit Support , gdb@sources.redhat.com Message-id: <200509231631.00570.jon.ringle@comdial.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <200509231538.36201.jon.ringle@comdial.com> <20050923195736.GA9159@nevyn.them.org> User-Agent: KMail/1.8.1 X-SW-Source: 2005-09/txt/msg00173.txt.bz2 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.