Date: Sat, 9 Apr 2005 19:47:03 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Panic in sbflush_locked Message-ID: <20050409194234.T4310@fledge.watson.org> In-Reply-To: <200504081725.06751.jhb@FreeBSD.org> References: <200504081725.06751.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 8 Apr 2005, John Baldwin wrote: > Got this while doing a buildworld -j 8 loop overnight on a PII Xeon x 4 > box: > > login: panic: sbflush_locked: cc 11 || mb 0xc22dad00 || mbcnt 0 If you can extract a core, I'd lke to see the contents of *sb in the sbflush_locked() frame, and if you don't mind hand-walking the sb_mb mbuf chain and printing the contents of each mbuf, that would be helpful. Basically, it looks like the accounting in the socket buffer is wrong/out of sync: the socket buffer mbuf count has hit zero, but there are still mbufs -- probably one, by the looks of it. We could be looking at a sosend/soreceive bug, I guess, but it's a bit hard to say. If this is reproduceable, it would be useful to run your system with "options SOCKBUF_DEBUG" which adds consistency checks to socket buffers at key moments, and might catch the corruption earlier. Robert N M Watson > cpuid = 3 > KDB: enter: panic > [thread pid 1673 tid 100117 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 1673 tid 100117 td 0xc216c170 > kdb_enter(c0702cab,3,c070658d,e010f9b8,100) at kdb_enter+0x30 > panic(c070658d,b,c22dad00,0) at panic+0x144 > sbflush_locked(e010fa24,1ea,e010f9ec,c05330d6,c0761c40) at sbflush_locked+0x91 > sbrelease_locked(e010fa24,c4d957c8,c070650f,240,c4d95858) at sbrelease_locked+0x12 > sbrelease(e010fa24,c4d957c8,0,0,c0738f00) at sbrelease+0x41 > sorflush(c4d957c8,0,c07064db,193,c279cb20) at sorflush+0x15f > sofree(c4d957c8,0,c07064db,1df,c070650f) at sofree+0x250 > soclose(c4d957c8,151,c279cb20,e010fb10,c04f6d38) at soclose+0x2e2 > fifo_cleanup(c527c6a8,c527c6a8,e010fb54,c216c170,e010fb30) at fifo_cleanup+0x2a > fifo_close(e010fb54,0,c07117d6,7b6) at fifo_close+0x68 > ufsfifo_close(e010fb54,e010fb80,c05a6286,c07444c0,e010fb54) at ufsfifo_close+0x7f > VOP_CLOSE_APV(c07444c0,e010fb54,c216c170,c209ac00,c0751ec0) at VOP_CLOSE_APV+0x3e > vn_close(c527c6a8,7,c2387380,c216c170,c0711ea9) at vn_close+0x76 > vn_closefile(c28a83a8,c216c170,e010fc14,c051b964,c28a83a8) at vn_closefile+0xf4 > fifo_close_f(c28a83a8,c216c170,c0700890,846,c28a83a8) at fifo_close_f+0x19 > fdrop_locked(c28a83a8,c216c170,c0700890,831) at fdrop_locked+0x94 > fdrop(c28a83a8,c216c170,e010fc70,c0523ba2,c075a940,c0700c04,2dc,c216c170,e010fd14,0,c216f9ec,e010fd14,c216c170,c216f9ec,e010fce4,e010fc90,c0515223,7,c3146ec8,0,3,c3146e00,e010fcb0,c051533d,c3146e00,0,3) at fdrop+0x3c > closef(c28a83a8,c216c170,c0700890,3ea,c216c170) at closef+0x3f2 > close(c216c170,e010fd14,4,e010fd3c,1) at close+0x1f2 > syscall(80b002f,2f,bfbf002f,bfbfd990,0) at syscall+0x2a0 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (6, FreeBSD ELF32, close), eip = 0x805ccf3, esp = 0xbfbfd96c, ebp = 0xbfbfd978 --- > db> x/x 0xe010fa24,20 > 0xe010fa24: 0 0 0 0 > 0xe010fa34: 0 0 c07336a8 c07064d4 > 0xe010fa44: c07064d4 30000 0 0 > 0xe010fa54: 0 c216c170 0 0 > 0xe010fa64: c22dad00 c22dad00 c22dad00 b > 0xe010fa74: 2000 0 10000 0 > 0xe010fa84: 1 0 40 0 > 0xe010fa94: c4d957c8 c4d957c8 0 e010fabc > > Box is still sitting in ddb if more info is desired. > > -- > John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050409194234.T4310>