|
Home > Archive > Unix Programming > March 2005 > Debugging Thread
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| Hi,
Does anyone know of any tool working under Solaris that could help
investigating about thread problems ?
I'm experiencing a deadlock situation that is difficult to reproduce
on the delopment platform but that happens too much often on the
production one.
So a cool thing would be to have something that allows me, perhaps
after having relinked my program, to monitor thread activity, state
and last activation time.
Perhaps I should mention that my application is not responsible for
the threads management, it's up to a "black box" library.
The important point for me is to detect that a thread is blocked for
too much time, in which case I could decide from another process to
kill it and go on.
Any advice is really welcome.
Loic
| |
| shakahshakah@gmail.com 2005-03-14, 5:57 pm |
| Can gdb attach to a running process? Though it doesn't help you
identify when you have deadlock, it might let you look to see what each
thread is doing once you notice the deadlock.
I've done the equivalent on Windows boxes a few times (using MS Visual
Studio), was pretty simple to identify the problem in those cases.
| |
| Pascal Bourguignon 2005-03-14, 5:57 pm |
| "shakahshakah@gmail.com" <shakahshakah@gmail.com> writes:
> Can gdb attach to a running process?
Yes, of course. Just use the attach command!
pgm1 & echo $!
gdb pgm1
attach ${PID_OF_pgm1_PROCESS}
> Though it doesn't help you
> identify when you have deadlock, it might let you look to see what each
> thread is doing once you notice the deadlock.
Well, I've never tried to debug threads with gdb, but I guess it
should be possible.
> I've done the equivalent on Windows boxes a few times (using MS Visual
> Studio), was pretty simple to identify the problem in those cases.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
| |
| Måns Rullgård 2005-03-14, 5:57 pm |
| Pascal Bourguignon <spam@mouse-potato.com> writes:
>
> Well, I've never tried to debug threads with gdb, but I guess it
> should be possible.
It sometimes works, but quite often all you get is a SIGSEGV in some
"impossible" place.
--
Måns Rullgård
mru@inprovide.com
| |
| Sean Burke 2005-03-14, 8:47 pm |
|
loicderoyand@yahoo.fr (LDD) writes:
> Hi,
>
> Does anyone know of any tool working under Solaris that could help
> investigating about thread problems ?
>
> I'm experiencing a deadlock situation that is difficult to reproduce
> on the delopment platform but that happens too much often on the
> production one.
> So a cool thing would be to have something that allows me, perhaps
> after having relinked my program, to monitor thread activity, state
> and last activation time.
> Perhaps I should mention that my application is not responsible for
> the threads management, it's up to a "black box" library.
>
> The important point for me is to detect that a thread is blocked for
> too much time, in which case I could decide from another process to
> kill it and go on.
Solaris includes the 'pstack' utility, which gives you a dump of the
stack traces for all of the process's threads. This is useful in
development to identify the threads that participate in a deadlock.
This does not help you decide when to kill and restart your process,
but it does enable you to gather useful diagnostic info when you do.
-SEan
| |
| Chuck Dillon 2005-03-15, 5:59 pm |
| LDD wrote:
> Hi,
>
> Does anyone know of any tool working under Solaris that could help
> investigating about thread problems ?
dbx
>
> I'm experiencing a deadlock situation that is difficult to reproduce
> on the delopment platform but that happens too much often on the
> production one.
> So a cool thing would be to have something that allows me, perhaps
> after having relinked my program, to monitor thread activity, state
> and last activation time.
> Perhaps I should mention that my application is not responsible for
> the threads management, it's up to a "black box" library.
>
> The important point for me is to detect that a thread is blocked for
> too much time, in which case I could decide from another process to
> kill it and go on.
>
> Any advice is really welcome.
>
> Loic
When a deadlock occurs generate a core file and use dbx to investigate.
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
|
|
|
|
|