Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Oct 2013 17:10:02 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-ia64@freebsd.org, mexas@bris.ac.uk
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic: uma_zfree: Freeing to non free bucket index.
Message-ID:  <201310151710.02551.jhb@freebsd.org>
In-Reply-To: <201310140844.r9E8iSYM015098@mech-cluster241.men.bris.ac.uk>
References:  <201310140844.r9E8iSYM015098@mech-cluster241.men.bris.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, October 14, 2013 4:44:28 am Anton Shterenlikht wrote:
> 
> BTW, I see in dmesg:
> 
> Starting ddb.
> ddb: sysctl: debug.ddb.scripting.scripts: Invalid argument
> /etc/rc: WARNING: failed to start ddb
> 
> What is that about?
> 
> 
> panic: uma_zfree: Freeing to non free bucket index.
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self(0x9ffc000000158380) at db_trace_self+0x40
> db_trace_self_wrapper(0x9ffc000000607370) at db_trace_self_wrapper+0x70
> kdb_backtrace(0x9ffc000000ed0e10, 0x9ffc00000058e660, 0x40c, 
0x9ffc0000010a44a0) at kdb_backtrace+0xc0
> vpanic(0x9ffc000000dfc468, 0xa0000000e26e0fd8, 0x9ffc000000ef9670, 
0x9ffc000000ed0bc0) at vpanic+0x260
> kassert_panic(0x9ffc000000dfc468, 0xe000000015e25f90, 0xe000000015e243e0, 
0xe00000027ffd5200) at kassert_panic+0x120
> uma_zfree_arg(0xe00000027ffccfc0, 0xe000000015e243e0, 0x0) at 
uma_zfree_arg+0x2d0
> g_destroy_bio(0xe000000015e243e0, 0x9ffc0000004ad4a0, 0x30a, 0x30a) at 
g_destroy_bio+0x30
> g_disk_done(0xe000000015e243e0, 0xe000000015e15d10, 0xe000000012672700, 
0x9ffc0000006b18c0) at g_disk_done+0x140
> biodone(0xe000000015e243e0, 0x9ffc000000e0e150, 0xe000000010c24030, 0x0, 
0x0, 0x0, 0x9ffc000000066890, 0x614) at biodone+0x180
> dadone(0xe000000012672600, 0xe000000012541000, 0xe000000015e243e0, 0x7) at 
dadone+0x620
> camisr_runqueue(0xe000000011a2dc00, 0xe000000012541054, 0xe000000012541000, 
0x135d) at camisr_runqueue+0x6c0
> camisr(0xe000000011a2dc20, 0xe000000011a2dc00, 0x9ffc000000bee9d0, 
0xa0000000e26e1548) at camisr+0x260
> intr_event_execute_handlers(0xe0000000111764a0, 0xe00000001118d998, 
0xe000000011191c00, 0x0) at intr_event_execute_handlers+0x280
> ithread_loop(0xe000000011192f00, 0xa0000000e26e1550, 0xe000000011192f14, 
0xe00000001118d99c) at ithread_loop+0x1b0
> fork_exit(0x9ffc000000e12a90, 0xe000000011192f00, 0xa0000000e26e1550) at 
fork_exit+0x120
> enter_userland() at enter_userland
> KDB: enter: panic
> [ thread pid 12 tid 100015 ]
> Stopped at      kdb_enter+0x92: [I2]    addl r14=0xffffffffffe2c990,gp ;;
> db> 
> 
> db> scripts
> lockinfo=show locks; show alllocks; show lockedvnods
> db> run lockinfo
> db:0:lockinfo> show locks
> db:0:locks>  show alllocks
> db:0:alllocks>  show lockedvnods
> Locked vnodes
> 
> 0xe00000001ab39ba8: tag ufs, type VDIR
>     usecount 1, writecount 0, refcount 3 mountedhere 0
>     flags (VI_ACTIVE)
>     v_object 0xe00000001cd30900 ref 0 pages 0
>     lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 
100121)
>         ino 5467932, on dev da5p1
> 
> 0xe000000015ed3ba8: tag ufs, type VDIR
>     usecount 1, writecount 0, refcount 3 mountedhere 0
>     flags (VI_ACTIVE)
>     v_object 0xe00000001cd33e00 ref 0 pages 0
>     lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 
100092)
>         ino 5467948, on dev da5p1
> 
> 0xe00000001ab16938: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 3 mountedhere 0
>     flags (VI_ACTIVE)
>     v_object 0xe00000001cd98a00 ref 0 pages 1
>     lock type ufs: EXCL by thread 0xe000000018494000 (pid 41337, cpdup, tid 
100137)
>         ino 5469420, on dev da5p1
> 
> 0xe00000001b2503b0: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 1 mountedhere 0
>     flags (VI_ACTIVE)
>     lock type ufs: EXCL by thread 0xe000000012a28900 (pid 41421, cpdup, tid 
100092)
>         ino 5469421, on dev da5p1
> 
> 0xe00000001ab2a760: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 1 mountedhere 0
>     flags (VI_ACTIVE)
>     lock type ufs: EXCL by thread 0xe0000000183d9680 (pid 41389, cpdup, tid 
100121)
>         ino 5469422, on dev da5p1
> db> 
> db> script zzz=textdump set; capture on; run lockinfo; show pcpu; bt; ps; 
alltrace; capture off; reset
> db> run zzz

I think 'reset' is going to reset without doing a dump?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310151710.02551.jhb>