panic: ffs_blkfree: freeing free block

I just upgraded my i386 Tinderbox machine last night, and a package
build triggered this panic.  I've been using this machine for Tinderbox
for a year or so now, and this is the first such panic I received.  The
disk in question is 61% used, and I am building locally using loopback
NFS mounts.

FreeBSD fugu.marcuscom.com 7.0-CURRENT FreeBSD 7.0-CURRENT #12: Sun Sep
30 02:14:27 EDT 2007
gnome_at_fugu.marcuscom.com:/space2/obj/usr/src/sys/FUGU  i386

I was previously running a kernel from September 19 without any
problems.

dev = ad6s1e, block = 22287592, fs = /space
panic: ffs_blkfree: freeing free block
cpuid = 0
KDB: enter: panic
Physical memory: 2038 MB
Dumping 351 MB: 336 320 304 288 272 256 240 224 208 192 176 160 144 128
112 96 80 64 48 32 16

#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:195
#1  0xc045ed89 in db_fncall (dummy1=-236168880, dummy2=0, dummy3=70, 
    dummy4=0xf1ec58bc "ð\022FÀ") at /usr/src/sys/ddb/db_command.c:486
#2  0xc045f2f5 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:401
#3  0xc0460d25 in db_trap (type=3, code=0)
at /usr/src/sys/ddb/db_main.c:222
#4  0xc0595316 in kdb_trap (type=3, code=0, tf=0xf1ec5a64)
    at /usr/src/sys/kern/subr_kdb.c:502
#5  0xc072d32f in trap (frame=0xf1ec5a64)
at /usr/src/sys/i386/i386/trap.c:621
#6  0xc07131fb in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc0595492 in kdb_enter (msg=0xc07706ef "panic") at cpufunc.h:60
#8  0xc056dda4 in panic (fmt=0xc077ee64 "ffs_blkfree: freeing free
block")
    at /usr/src/sys/kern/kern_shutdown.c:547
#9  0xc0698954 in ffs_blkfree (ump=0xc5140300, fs=0xc508a800, 
    devvp=0xc5167990, bno=22287592, size=16384, inum=5566594)
    at /usr/src/sys/ufs/ffs/ffs_alloc.c:1893
#10 0xc06ac318 in indir_trunc (freeblks=0xcf6d4000, dbn=89113600,
level=0, 
    lbn=12, countp=0xf1ec5c4c)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:2896
#11 0xc06ac5f7 in handle_workitem_freeblocks (freeblks=0xcf6d4000,
flags=0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2746
#12 0xc06add8e in process_worklist_item (mp=0xc512029c, flags=Variable
"flags" is not available.
)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:963
#13 0xc06aedb2 in softdep_process_worklist (mp=0xc512029c, full=0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:847
#14 0xc06b127d in softdep_flush ()
at /usr/src/sys/ufs/ffs/ffs_softdep.c:758
#15 0xc054d5b9 in fork_exit (callout=0xc06b0e00 <softdep_flush>,
arg=0x0, 
    frame=0xf1ec5d38) at /usr/src/sys/kern/kern_fork.c:796
#16 0xc0713270 in fork_trampoline ()
at /usr/src/sys/i386/i386/exception.s:205

I know this backtrace may not be all that useful since this is an
assertion, but I wanted to know if there was perhaps a recent change
that went in that could account for this new behavior.  Thanks.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome_at_FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome