Hi Kelly, On 8 Nov 2012, at 14:55, Kelly Caudill wrote: > > but I do not understand why it does not combine some entries like: > > lwp 5 slept (tot=0ms) 0 times (avg=30000ms) like this: > libc.so.1`__lwp_park+0x10 > libc.so.1`cond_wait_queue+0x4c > libc.so.1`cond_wait_common+0x2d4 > libc.so.1`_cond_timedwait+0x34 > libc.so.1`cond_timedwait+0x14 > libc.so.1`pthread_cond_timedwait+0xc > libnspr4.so`pt_TimedWait+0xe0 > libnspr4.so`PR_WaitCondVar+0x190 > libnspr4.so`PR_Wait+0x1c > libmqcrt.so.1`0xffffffff57657c48 > libnspr4.so`_pt_root+0xa8 > libc.so.1`_lwp_start > > lwp 5 slept (tot=0ms) 0 times (avg=30000ms) like this: > libc.so.1`__lwp_park+0x10 > libc.so.1`cond_wait_queue+0x4c > libc.so.1`cond_wait_common+0x2d4 > libc.so.1`_cond_timedwait+0x34 > libc.so.1`cond_timedwait+0x14 > libc.so.1`pthread_cond_timedwait+0xc > libnspr4.so`pt_TimedWait+0xe0 > libnspr4.so`PR_WaitCondVar+0x190 > libnspr4.so`PR_Wait+0x1c > libmqcrt.so.1`0xffffffff57657c48 > libnspr4.so`_pt_root+0xa8 > libc.so.1`_lwp_start > > lwp 5 slept (tot=0ms) 0 times (avg=30000ms) like this: > libc.so.1`__lwp_park+0x10 > libc.so.1`cond_wait_queue+0x4c > libc.so.1`cond_wait_common+0x2d4 > libc.so.1`_cond_timedwait+0x34 > libc.so.1`cond_timedwait+0x14 > libc.so.1`pthread_cond_timedwait+0xc > libnspr4.so`pt_TimedWait+0xe0 > libnspr4.so`PR_WaitCondVar+0x190 > libnspr4.so`PR_Wait+0x1c > libmqcrt.so.1`0xffffffff57657c48 > libnspr4.so`_pt_root+0xa8 > libc.so.1`_lwp_start > > Those are just one example of thread stacks that seem identical but were not > combined into a single aggregation bucket. > > Some of the numbers are 0 due to the trun(xx,N) before the print - because I > only want to see the (hopefully) few worst offenders. > > But since it does not combine them properly, the list is overwhelmed with > like above which, unfortunately, are a case I don't actually care about. If > it combined those, then I the other few printed should be what I do care > about. > > Am I doing something wrong?
You're not doing anything wrong. This is a known limitation that arises from the fact that the aggregation key generated by the ustack() action includes the PID. The PID itself isn't displayed; it's used to enable the user-land component to perform the address-to-name translation against the correct process. Robert _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org