This is the mail archive of the gdb@sourceware.org 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]

Re: thread id is lost when viewing list of threads in slickedit


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.


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