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
pgpKdhWFjvPPl.pgp
Description: PGP signature
