curstk is I believe calculated based on the threads top of stack. On Linux and Solaris (at least, not sure if there are any others off the top of my head) we switched to using a alternative stack for signal handling. And in the signal handling code w...
显示全部curstk is I believe calculated based on the threads top of stack. On Linux and Solaris (at least, not sure if there are any others off the top of my head) we switched to using a alternative stack for signal handling. And in the signal handling code we do a switch thread to ourself, which would save the Top of stack in the signal stack into the tcb->mt_stack (which is I believe used to compute that curstk value). So if we are using a alternative signal stack, and this thread was in the signal handling code, then you could see crazy values for it in that onstat -g ses output and probably also onstat -g sts The other possibility would just be that the tcb->mt_stack structure itself somehow got corrupted which could make that output look like garbage
so tell customer that if there are no any warning that stack overflow, and they can ignore the onstat -g ses curstk size info, and they can use onstat -g sts output to check the stack size.
收起