STREAMS/UX for the HP 9000 Reference Manual

202
Debugging STREAMS/UX Modules and Drivers
Debugging Examples
First we translate the hex stack trace in the panic message into procedure
names and addresses. Using the adb i command for each of the hex
addresses in the panic message stack trace, we get the following symbolic
stack trace:
panic+40: addil 800,dp
trap+0xA28: b trap+0xF18
$call_trap+20: rsm 1,r0
spput+4C: stws r31,0(r1)
csq_lateral+80: b,n csq_lateral+8C
puthere+4C: ldw -54(sp),rp
lmodcsrv+5C: bl getq,rp
sq_wrapper+50: ldw -54(sp),rp
csq_lateral+80: b,n csq_lateral+8C
runq_run+58: b,n runq_run+74
str_sched_daemon+264: b str_sched_daemon+160
The address where the illegal data access occurred is spput+4C. The isr.ior
in the panic message indicates that the data address that caused the panic is
0.0, and the instruction at spput+4C is stws r31,0(r1), so r1 must have been 0
at the time of the panic. We are probably dereferencing a null pointer. Our
first task is to find out which pointer this is. To do this we need to know to
which source code line spput+4C corresponds to. Here is the source code
for spput():
struct sp {
unsigned sp_state;
queue_t *sp_rdq;
mblk_t *mp;
mblk_t *last_mp;
};
static spput(q, mp)
queue_t *q;
mblk_t *mp;
{
struct sp *lp;
unsigned int s;
switch (mp->b_datap->db_type) {
case M_DATA:
case M_PROTO:
case M_PCPROTO:
lp = q->q_ptr;
if (!lp->mp)
lp->mp = mp;
else
lp->last_mp->b_next = mp;
lp->last_mp = mp;
timeout(sp_timeout,lp,1);
break;
default: