6.3-RELEASE panic

Norbert Papke fbsd-ml at scrapper.ca
Wed Jan 23 08:36:16 PST 2008


On January 23, 2008, John Baldwin wrote:
> On Monday 21 January 2008 04:51:54 pm Kris Kennaway wrote:
> > Petr Holub wrote:
> > > Hi,
> > >
> > > I've just updated the 6.2-RELEASE to 6.3-RELEASE using freebsd-update
> > > as described in daemonology blog.
> > >
> > > While removing the old packages using
> > > pkg_delete -af
> > > I've tried to stop all the deamons from /usr/local/etc/rc.d and
> > > got the following panic (hand transcribed from a photo - I don't have
> > > that machine enabled for remote debugging). Panic seems to be
> > > deterministic when stopping those scripts (verified by subsequent
> > > attempts while pkg_delete was not running).
> > >
> > > (kgdb) bt
> > > #0  0xc06a46a6 in doadump ()
> > > #1  0xc06a4b76 in boot ()
> > > #2  0xc06a4e0c in panic ()
> > > #3  0xc090d1b4 in trap_fatal ()
> > > #4  0xc090cf1b in trap_pfault ()
> > > #5  0xc090cb59 in trap ()
> > > #6  0xc08f9fea in calltrap ()
> > > #7  0xc073fa6f in in_delmulti ()
> > > #8  0xc0748e15 in ip_freemoptions ()
> > > #9  0xc07414cc in in_pcbdetach ()
> > > #10 0xc075a0ee in udp_detach ()
> > > #11 0xc06de0b8 in soclose ()
> > > #12 0xc06cd83b in soo_close ()
> > > #13 0xc0683ffc in fdrop_locked ()
> > > #14 0xc0683f25 in fdrop ()
> > > #15 0xc0682553 in closef ()
> > > #16 0xc067f8e7 in kern_close ()
> > > #17 0xc067f6d8 in close ()
> > > #18 0xc090d4cb in syscall ()
> > > #19 0xc08fa03f in Xint0x80_syscall ()
> > > #20 0x00000033 in ?? ()
> > > Previous frame inner to this frame (corrupt stack?)
> >
> > Can you obtain a trace against the kernel.symbols?
>
> I've been seeing this panic (and several variations of) for quite a while
> on 6.x.  It appears that a socket is being double-closed somehow.  I
> usually see it during exit1() when a process' file descriptor table is
> being freed.  I've spent a lot of time looking for a fd reference count
> leak or some such but haven't found one yet. :(  I've also seen panics
> with vnodes having a ref cnt underflow in vrele or vput, so I've wondered
> if it's a fd-level bug that affects both vnodes and sockets rather than
> separate socket and vnode bugs.

For comparison, here is the callstack from the panic reported in kern/116077.  
The PR has symbolic information.

#0 doadump ()
#1 0xc055293e in boot 
#2 0xc0552c95 in panic
 #3 0xc06e6232 in trap_fatal
#4 0xc06e5f3b in trap_pfault
#5 0xc06e5b51 in trap 
#6 0xc06d0b1a in calltrap ()
#7 0xc05e3e6f in in_delmulti
#8 0xc05ed8e9 in ip_freemoptions
#9 0xc05e5d6c in in_pcbdetach
#10 0xc05fee96 in udp_detach
#11 0xc058e710 in soclose
#12 0xc057db3f in soo_close
#13 0xc052fd9c in fdrop_locked 
#14 0xc052fcc5 in fdrop 
#15 0xc052e263 in closef
#16 0xc052d253 in fdfree
#17 0xc0536b4b in exit1 
#18 0xc05366b0 in sys_exit
#19 0xc06e6577 in syscall
#20 0xc06d0b6f in Xint0x80_syscall () 
#21 0x00000033 in ?? ()

It is also triggered when a multi-cast client shuts down.  The patch in the PR 
fixes this issue for me.  I have been running with it since November.

Cheers.


More information about the freebsd-stable mailing list