Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 6 Jan 2007 12:01:51 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Ceri Davies <ceri@submonkey.net>
Cc:        stable@FreeBSD.org
Subject:   Re: (audit?) Panic in 6.2-PRERELEASE
Message-ID:  <20070106120040.N46119@fledge.watson.org>
In-Reply-To: <20070105150857.GC7088@submonkey.net>
References:  <20070105111954.GA51511@submonkey.net> <20070105120539.H46119@fledge.watson.org> <20070105131528.GB7088@submonkey.net> <20070105133028.F98541@fledge.watson.org> <20070105150857.GC7088@submonkey.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

thanks,

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070106120040.N46119>