Let's dig a bit further and find out what the stack looks like. We'll start at the stack pointer stored in the trap registers. %o6 contains the stack pointer we need. f0ac9608/16X 0xf0ac9608: 1 0 0 0 3 1 f015cd94 f016ffac fc61607c 80 fc6ca580 1 19f8309 fc61607c f0ac9668 f00ee640 f00ee640/i stubs_common_code+0x6c: jmpl %g1, %o7 f0ac9668/16X 0xf0ac9668: 0 f0ac9858 f016b068 fc61607c 0 f015cd9c ffffffe0 1424d5e8 fc61607c 80 fc6ca580 1 19f8309 fc61607c f0ac9760 fc606ca0 fc606ca0/i semctl+0x664: call acct + 0x54 f0ac9760/16X 0xf0ac9760: 404000c7 f008534c fc607824 2 fc0af000 f027bd44 0 f016ffac f0ac9e94 f0ac9920 f0ac9e94 1 fc607800 fc6ca580 f0ac9858 fc607a14 fc607a14/i semsys+0x40: call semctl f0ac9858/16X 0xf0ac9858: 404000c0 fc6079d0 f016b068 1a 0 0 fc03c4c0 fc03c4c0 f0ac9e94 f0ac9920 0 0 0 fc607b04 f0ac98b8 f0070898 f0070898/i syscall+0x3e4: jmpl %g1, %o7 f0ac98b8/16X 0xf0ac98b8: 88 1 f01567ac 0 fc0af000 35 f0ac9994 f0ac99e0 f0160dec f0ac9eb4 0 f0ac9e90 fffffffc ffffffff f0ac9938 f0041aa0 f0041aa0/i _sys_rtt+0x4d8: call syscall f0ac9938/16X 0xf0ac9938: 40900082 ef76b254 ef76b258 20 88 4 7 f0ac9938 35 0 8d03 1 8 0 effff138 ef790f04 ef790f04/i data address not found The stack traceback shows that a system call was made that resulted in a call to the semsys() routine. Did you notice that the $c output did not match the stack traceback output? When looking at system crashes that resulted from a trap, it is important to remember to use the stack pointer in the trap's register. Otherwise, you may not get an accurate picture of the most recent activity. |