Re: Panic in sbflush_locked

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_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>