Walking the stack by hand

Since we trap'ed instead of panic'ed, it is a good idea to manually walk through the stack to get a more accurate picture of the stack traceback. Doing this one time will allow us to use the adb $c command with an understanding of how accurate its output is. Let's walk the stack, starting at register %o6 , as seen in the regs structure shown above.

  f86e8d08/16X  0xf86e8d08:     2               1000            ffef            fffe                  5004            1a              1a              0                  fceaccb0        f86e8eac        0               fceb2525                  2               0  f86e8d68        f80618ec   f80618ec/i  _vno_rw+0xa4:   jmpl    %g1, %o7  f86e8d68/16X  0xf86e8d68:     f7743a14        7fffffff        f80ca554        f7745ae4                  f7748bec        f7745df0        f774429c        19d1                  f835bac8        1               f86e8eac        1000                  fceaccb4        0  f86e8dc8        f804cb20   f804cb20/i  _rwuio+0x2b0:   jmpl    %g1, %o7  f86e8dc8/16X  0xf86e8dc8:     f835bac8        f81170b0        0               f86e8eac                  f835bac8        102             1000            f835bac8                  f835bac8        f86e8eac        f86e8ea4        1000                  1000            f86e8eac        f86e8e40        f804bab4  and so on  

We could continue walking the stack, but we've already accomplished what we needed to. We have confirmed that the $c output we are interested in starts with fifo_rdwr(). The reference to uiomove() is actually a lingering, historical frame on the stack, and tells us that uiomove() was the most recent routine called by fifo_rdwr() .

From both the stack traceback and the manual stack traceback, we can see that when fifo_rdwr() was called, register %i3 contained 0xfceb2525. This value does not represent a full-word address, not even a half-word address. 0xfceb2525 only represents a byte address. The instruction used in the fifo_rdwr() routine was a full word load instruction, ld, so the value in %i3 is suspicious at best.

Note

Unfortunately, it is possible that the fifo_rdwr() routine may have used register %i3 as a local register after it finished reading its contents as a calling parameter , thus modifying %i3 , thus affecting the stack traceback information that we see in the postmortem files.

Let's check the assembly code of fifo_rdwr() to see whether %i3 has been modified since entering the routine.