Subj : Re: Stack Tracing in multi-threaded programs To : comp.programming.threads From : Paul Pluzhnikov Date : Wed May 25 2005 07:56 am suman writes: Please do not top-post, and read this: http://catb.org/~esr/jargon/html/T/top-post.html > 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 > .... It is unlikely that there exists any pthread environment in which a stack trace for any thread looks like that. You probably misunderstood what you read. > 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. Why do you want to assume anything? Just try it and see if it works. One of the problems that your stack dumper will have to deal with is that the top of any non-initial thread has a function that necessarily does not have a frame pointer. So even if all of your code is non-optimized, you will still encounter "optimized" code somewhere on the stack, and your stack walk routine still has to understand what to do at that point. > 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?? There is no portable way that I know of. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. .