I'm currently trying to track down some memory corruption in a heavily
multi-threaded application.  So, when a corruption occurs, I'd like to
take a snapshot of all threads, to see what they're doing.

I've looked at proc(5), and at kstkeip, but it's value is outside of
the range [startcode-endcode], and outside of my program's address
space.  I'm assuming I'm having some virtual-vs-physical memory
address problems.

So, perhaps I'm approaching this incorrectly.  Is there a way for one
thread to spin through the other threads and grab current instruction
pointers?

And, would it also be possible to grab stack pointers *and* walk the
stacks of the other threads?

Or, am I stuck with having to signal each thread to dump it's own
pointers/stack?

Please respond by e-mail,


-Dave

[ Post a follow-up to this message ]

chaos@mindspring.com (David Frascone) writes:
quote:

> I'm currently trying to track down some memory corruption in a heavily
> multi-threaded application.  So, when a corruption occurs, I'd like to
> take a snapshot of all threads, to see what they're doing.


valgrind is usually helpful with finding that sort of bugs.
quote:

> I've looked at proc(5), and at kstkeip, but it's value is outside of
> the range [startcode-endcode], and outside of my program's address
> space.  I'm assuming I'm having some virtual-vs-physical memory
> address problems.
>
> So, perhaps I'm approaching this incorrectly.  Is there a way for one
> thread to spin through the other threads and grab current instruction
> pointers?
>
> And, would it also be possible to grab stack pointers *and* walk the
> stacks of the other threads?
>
> Or, am I stuck with having to signal each thread to dump it's own
> pointers/stack?


GDB can do all that for you.  Run "gdb program pid-of-program" to
attach to a running instance of the program.

--
Måns Rullgård
mru@kth.se

[ Post a follow-up to this message ]

mru@kth.se (Måns Rullgård) wrote in message news:<yw1xptduh5t5.fsf@kth.se>...
quote:

> chaos@mindspring.com (David Frascone) writes:
> 
>
> valgrind is usually helpful with finding that sort of bugs.


Sorry, forgot to mention: the architecture is PPC.
quote:
 
>
> GDB can do all that for you.  Run "gdb program pid-of-program" to
> attach to a running instance of the program.


I need this for a crash file, for post-mortem debugging. 

-Dave

[ Post a follow-up to this message ]