Date: Wed, 23 Jan 2008 09:28:22 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Petr Holub <hopet@ics.muni.cz>, Kris Kennaway <kris@freebsd.org>, rwatson@freebsd.org, stable@freebsd.org Subject: Re: 6.3-RELEASE panic Message-ID: <200801230928.23047.jhb@freebsd.org> In-Reply-To: <479513FA.6020802@FreeBSD.org> References: <004b01c85c4e$e1c44540$a54ccfc0$@muni.cz> <479513FA.6020802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801230928.23047.jhb>