* Re: thread id is lost when viewing list of threads in slickedit
[not found] <ECCC6E9907B4CD4A83260A191A91F20E6AC697@wampa.office.slickedit.com>
@ 2005-09-23 19:40 ` Jon Ringle
2005-09-23 19:57 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Jon Ringle @ 2005-09-23 19:40 UTC (permalink / raw)
To: SlickEdit Support; +Cc: gdb
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?
Jon
> When debugging a program from within slickedit, the list of thread IDs is
> lost. This information is crucial when trying to debug a deadlock.
>
> When you use gdb at the console, this information is printed as the 3rd
> word of each line with the info threads command:
> (gdb) info threads
> 10 thread 8201 0x4014ebc4 in __sigsuspend (set=0xbe9ffb9c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 9 thread 7176 0x4014ebc4 in __sigsuspend (set=0xbebffc44) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 8 thread 6151 0x4014ebc4 in __sigsuspend (set=0xbedffa04) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 7 thread 5126 0x401a5ce4 in > nanosleep () from /home/build/mp1000/2.80.018/Release/Soundpipe/install/lib/libc.so.6
> 6 thread 4101 0x4014ebc4 in __sigsuspend (set=0xbf1ffc0c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 5 thread 3076 0x401bf5fc in select () from /home/build/mp1000/2.80.018/Release/Soundpipe/install/lib/libc.so.6
> 4 thread 2051 0x4014ebc4 in __sigsuspend (set=0xbf5ffa3c) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 3 thread 1026 0x4014ebc4 in __sigsuspend (set=0xbf7ffc48) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> * 2 thread 2049 0x401bdf44 in __poll (fds=0x214d810, nfds=1, timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:45
> 1 thread 1024 0x401a5ce4 in nanosleep () from /home/build/mp1000/2.80.018/Release/Soundpipe/install/lib/libc.so.6
On Friday 23 September 2005 03:16 pm, SlickEdit Support wrote:
> Jon,
>
> SlickEdit uses the MI interface to talk to gdb and query for information
> (like threads). After doing a little digging into this, we have determined
> that the MI query for threads does not give us the thread ids you are
> seeing in the console text interface (i.e. running gdb from a console).
> Instead we are given a consecutive list of "thread ids". This is all we
> have to work with. The thread ids you are interested in _are_ listed in
> some information messages we get from gdb, but there is no way for us to
> map these to our consecutively numbered "thread ids" we get from gdb.
>
> So, the bottom line is that we do not have a fix or workaround for you, but
> I wanted you to understand why.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: thread id is lost when viewing list of threads in slickedit
2005-09-23 19:40 ` thread id is lost when viewing list of threads in slickedit Jon Ringle
@ 2005-09-23 19:57 ` Daniel Jacobowitz
2005-09-23 20:32 ` Jon Ringle
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2005-09-23 19:57 UTC (permalink / raw)
To: Jon Ringle; +Cc: SlickEdit Support, gdb
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. If you upgrade to NPTL, you'll find they get a lot less
intelligible.
You'd need an implementation of the documented -thread-info or
-thread-list-all-threads commands, which have never been defined.
Interesting, another item for my MI-using tools list...
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: thread id is lost when viewing list of threads in slickedit
2005-09-23 19:57 ` Daniel Jacobowitz
@ 2005-09-23 20:32 ` Jon Ringle
0 siblings, 0 replies; 3+ messages in thread
From: Jon Ringle @ 2005-09-23 20:32 UTC (permalink / raw)
To: SlickEdit Support, gdb
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-09-23 20:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <ECCC6E9907B4CD4A83260A191A91F20E6AC697@wampa.office.slickedit.com>
2005-09-23 19:40 ` thread id is lost when viewing list of threads in slickedit Jon Ringle
2005-09-23 19:57 ` Daniel Jacobowitz
2005-09-23 20:32 ` Jon Ringle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).