STREAMS/UX for the HP 9000 Reference Manual

215

Debugging STREAMS/UX Modules and Drivers

Debugging Examples

Using the adb i command, we can ﬁnd out the name of the qi_putp routine:

0x785ac/i

lmodcput:

lmodcput: stw rp,-14(sp)

This means the module lmodc was using the queue on which the panic

occurred. We can double check this by looking at the qi_minfo structure in

strdb. Again, we can either use :x module_info 0x294148, or we could see if

there is a navigation key available for qi_minfo:

navigation for structure qinit

'i' = qi_minfo (module_info)

's' = qi_mstat (module_stat)

Using the qinit i navigation key to print the module_info structure:

struct module_info 0x294148 S:5

mi_idnum = 0x3ec

mi_idname = 0x23a0a8

mi_minpsz = 0

mi_maxpsz = 256

mi_hiwat = 0x8000

mi_lowat = 0x4000

and using the adb s command to print mi_idname as a string:

0x23a0a8/s

lmcinfo+10: lmodc

So we had the panic occur on an lmodc read queue which was in the process

of being closed. Our stack trace conﬁrms this. We are making the exit

system call, close all open ﬁle descriptors and as part of process clean-up.

The last close of a stream causes each module and driver to be popped and

its resources freed, including its message buffers. Whenever a panic occurs

which involves b_datap being NULL, the cause is usually that the buffer has

already been freed but a pointer to it was not zeroed out, and a module or

driver continues to access the buffer through this non-zeroed pointer. The

best way to ﬁnd the cause of this problem is to look through the source code

for all calls to freemsg() or freeb(), and check that all pointers to the buffer

being freed are zeroed out.