(audit?) Panic in 6.2-PRERELEASE

[Ceri Davies]

On Sat, Jan 06, 2007 at 12:01:51PM +0000, Robert Watson wrote:
> On Fri, 5 Jan 2007, Ceri Davies wrote:
> 
> >On Fri, Jan 05, 2007 at 01:34:04PM +0000, Robert Watson wrote:
> >>
> >>On Fri, 5 Jan 2007, Ceri Davies wrote:
> >>
> >>>>Much as I would love to trust the contents of ub there, I suspect they 
> >>>>can't be trusted.  Could you print the contents of *fp in kern_fstat() 
> >>>>in both of those stacks?  I'd particularly like to know the value of 
> >>>>fp->f_type, and then depending on the type, possibly the contents of 
> >>>>*(struct vnode *)fp->f_vnode for DTYPE_VNODE/TYPE_FIFO or *(struct 
> >>>>socket *)fp->f_data in the case of DTYPE_SOCKET.
> >>>
> >>>Can you tell me how to get at *fp given that the stack trace shows 
> >>>fstat() and not kern_fstat()?  Sorry if I'm being dumb but I don't know 
> >>>how to step into the kern_fstat() call from fstat().
> >>
> >>It could be that the stack is hosed losing the frame, or maybe it's 
> >>inlined (more likely the former I think, as kern_fstat() is a symbol used 
> >>elsewhere in the kernel).  The best bet may be to use the file descriptor 
> >>number (uap->fd) to pull the struct file reference out of the process.  
> >>Something on the order of (td->td_proc->p_fd->fd_ofiles[fd]) should 
> >>return the right struct file *.
> >
> >OK, got it.  They're both sockets, data in the attachments.
> >
> >>How reproduceable is this?
> >
> >So far it's happened this morning and yesterday morning.  I haven't seen 
> >it before that.  I don't know the cause so I can't reproduce it at will, 
> >but the logs don't give any indication.  Chances are that it will happen 
> >again tomorrow, but we'll see.
> 
> Hmm.  It looks like you printf *(td->td_proc->p_fd->fd_ofiles) without the 
> array index.  Could you repeat that, but with the array index -- i.e., 
> td->td_proc->p_fd->fd_ofiles[uap->fd]?  Also, it would probably be useful 
> to print uap->fd.  Right now you're printing stdin (index 0), but if the 
> index is non-0, we want a different file.

Very tactfully put :)  Sorry about that.

None of the uap->fd's seem to be valid.
In the first case, uap->fd is way too high for the length of fd_ofiles,
which only has 21 elements:

(kgdb) up 8
#8  0xc04c470d in fstat (td=0xc2eeb180, uap=0xd610dc74) at /usr/src/sys/kern/kern_descrip.c:1075
1075            error = kern_fstat(td, uap->fd, &ub);
(kgdb) p uap->fd
$1 = 89
(kgdb) p *td->td_proc->p_fd->fd_ofiles[uap->fd]
Cannot access memory at address 0x0

In the second, uap->fd is nonsense:

(kgdb) up 8
#8  0xc04c470d in fstat (td=0xc3109300, uap=0xd617ec74) at /usr/src/sys/kern/kern_descrip.c:1075
1075            error = kern_fstat(td, uap->fd, &ub);
(kgdb) p uap->fd
$1 = -1023449232
(kgdb)

Ceri
-- 
That must be wonderful!  I don't understand it at all.
                                                  -- Moliere
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070106/fa0d3dd2/attachment.pgp