RE: IDS 9.20 with a single cpu vp

Wont pstack <pid> give what you want?? > > I guess a little more explaination is in order.... > > The only way that you can create a stack trace is via the > return address from a > call function. This may or may not yet be in the physical > stack memory. For > instance, with Solaris, there is a so called circular > register stack which > remains within the cpu register set. This regiseter stack is > not actually moved > to the memory portion of the stack unless there is an > overflow of the cpu > register stack memory. Otherwise, the register stack remains > only in the > processor registers. Even on those platforms which utilize > the stack memory > directly, the 'current' function will not appear until that > function makes a call > to another function. This is because it's the return address > that appears in the > stack and identifies the functions within the stack.. Also, > the currently > running thread will be constantly changing it's stack, > especially the memory near > the top of the stack. (Bottom on those platforms whose stack > grows down.) > Because of all of this, it becomes rather difficult to get a > stack trace of the > currently running function except by the "kill -7" technique > or by attaching with > some form of a debugger. > > > > Madison Pruet wrote: > > > It is rather difficult to get the stack for a running thread. > > > > smooth1 wrote: > > > > > Madison Pruet wrote in message <399F4FA2.75F504DB@home.com>... > > > >Neil, > > > > > > > > > > >We need to get several stack traces when the hang is > happening. This will > > > give > > > >some idea as to what the thread is doing that is hanging > the instance. On > > > most > > > >platforms you can do this by issueing a "kill -7 > <pid_of_cpuvp>. BUT WATCH > > > >OUT... On some platforms this will cause a crash. I > know that DEC will > > > crash. > > > > > > What about onstat -g stk <thread-id> ? >

Yes - if you are running solaris 2.6+ "Watson, Paul" wrote: > Wont pstack <pid> give what you want?? > > > > > I guess a little more explaination is in order.... > > > > The only way that you can create a stack trace is via the > > return address from a > > call function. This may or may not yet be in the physical > > stack memory. For > > instance, with Solaris, there is a so called circular > > register stack which > > remains within the cpu register set. This regiseter stack is > > not actually moved > > to the memory portion of the stack unless there is an > > overflow of the cpu > > register stack memory. Otherwise, the register stack remains > > only in the > > processor registers. Even on those platforms which utilize > > the stack memory > > directly, the 'current' function will not appear until that > > function makes a call > > to another function. This is because it's the return address > > that appears in the > > stack and identifies the functions within the stack.. Also, > > the currently > > running thread will be constantly changing it's stack, > > especially the memory near > > the top of the stack. (Bottom on those platforms whose stack > > grows down.) > > Because of all of this, it becomes rather difficult to get a > > stack trace of the > > currently running function except by the "kill -7" technique > > or by attaching with > > some form of a debugger. > > > > > > > > Madison Pruet wrote: > > > > > It is rather difficult to get the stack for a running thread. > > > > > > smooth1 wrote: > > > > > > > Madison Pruet wrote in message <399F4FA2.75F504DB@home.com>... > > > > >Neil, > > > > > > > > > > > > > >We need to get several stack traces when the hang is > > happening. This will > > > > give > > > > >some idea as to what the thread is doing that is hanging > > the instance. On > > > > most > > > > >platforms you can do this by issueing a "kill -7 > > <pid_of_cpuvp>. BUT WATCH > > > > >OUT... On some platforms this will cause a crash. I > > know that DEC will > > > > crash. > > > > > > > > What about onstat -g stk <thread-id> ? > >