Subj : Re: Stack Tracing in multi-threaded programs
To   : comp.programming.threads
From : suman
Date : Wed May 25 2005 02:13 pm

My stack dumper "solely" relies on frame pointers.
And you are very correct in observing that in case of optimized programs 
sometimes the stack frames are chopped off /coalesced. So my stack dumper works 
only with debug mode not with optimize mode.
I just wanted to know the ebp structure in case of threaded programs.
I am using Posix Threads. I have read somwhere that the stack trace in case of 
threaded program looks like this

main
manager_thread
thread1
thread2
thread3
.....

So is it correct to assume that my stack dumper will be able to print the stack 
trace correctly(assuming that it's run with debug mode) in case of a thread 
programs.

One more question is how do u know if an executable is going to be 
single-threaded or multi-threaded!!!(Like before i pass the executable to my 
stack_dumper is it possible for stack_dumper to know "quickly", possibly using 
some macro or something, whether the input executable is multi-threaded or 
signel-threaded??

Regards,
Suman

Paul Pluzhnikov wrote:

> suman <suman.kumar@oracle.com> writes:
> 
> 
>>My doubt is what happens to
>>the ebp-structure in case of a multi-threaded program. Is it the same
>>as a non-threaded case 
> 
> 
> Yes.
> 
> 
>>or this ebp structure gets destroyed!! 
> 
> 
> No.
> 
> 
>>Can i use the same stack-dumper for multi-threaded programs also??
> 
> 
> You should be able to, provided your stack_dump() knows how to
> deal with functions that do not have a frame pointer (optimized or
> assembly-coded functions).
> 
> 
>>In case of non-threared programs the stack trace looks like this
>>
>>read
>>__libc_start_main
>>main
> 
> ...
> 
> The level above __libc_start_main() is bogus, so your stack_dump()
> does not know how to deal with at least that case. 
> 
> What does your stack trace look like in the MT case?
> 
> Cheers,

.