Data address not found? Dig deeper

Data address not found? Dig deeper!

Using the allthreads file as a reference, we will manually display the top stack of the "missing" threads. This is hard, manual labor, but is sometimes worth it.

Of the 43 missing threads, all but five were in a cvwait() routine (or a variation of same), waiting for a condition variable to be met before continuing with execution. We've already seen three of them.

Here are the other two threads that were not in cvwait() .

  *(e18d2ec0+28)/16X  0xe18d2c40:     e1937ec0        e00fd240        e00de794        e0000000                   e0000000        ffffffe0        f5fde910        f5fde915  f5fde910  f5fde916        f5fde910        b36940ff                   f5a98ebb        f5a98ea0        e18d2ca0  f5fd1334   f5fd1334/i  abc_doit+0x14:      call    mutex_enter  *(f6226e00+28)/16X  0xe1eb36d0:     e1937ec0        e00fd240        e00de794        e0000000                   e0000000        ffffffe0        f5490308        f549030d  f5490308  f549030e        f5490308        ab9770ff                   f5a98f3b        f5a98f20        e1eb3730  f5499ca0   f5499ca0/i  ufs_update+0x18:                call    mutex_enter 

Very interesting! Two more calls to mutex_enter() ! Let's find out which mutex locks these two threads are trying to access.

  f5fde910$<mutex  abc_last_mutex:  abc_last_mutex: owner  f66d2800  abc_last_mutex:  abc_last_mutex: lock    type    waiters                  ff      0       ea02  f5490308$<mutex  0xf5490308:     owner  f572ee00  0xf5490308:     lock    type    waiters                  ff      0       f202 

We've not seen thread f572ee00 before, but thread f66d2800 certainly is familiar to us!