[issue1672] panic (trap 12) around btree_search() in 2.4.1-RELEASE
dillon at apollo.backplane.com
Fri Feb 12 10:49:49 PST 2010
:New submission from Joe "Floid" Kanowitz <jkanowitz at snet.net>:
:Using 2.4.1 with the lone patch from http://bugs.dragonflybsd.org/issue1583
:DragonFly tucker 2.4.1-RELEASE DragonFly v18.104.22.168.ga038d-RELEASE #1: Sat Jan 30
:11:57:51 EST 2010 root at tucker:/usr/obj/usr/src/sys/GENERIC i386
:... I'm not sure when this occurred; possibly during nightly cleanup.
:The previous evening gave HAMMER a little more stress than usual via a bit of
:`undo` usage (normally none) which did seem to be turning up transient(?)
:"ITERATE ENTIRE HISTORY: Unknown error: 0" results similar to
:http://leaf.dragonflybsd.org/mailarchive/users/2009-09/msg00062.html (but here
:the HAMMER config is left at the sane defaults). Not intending to poke at them
:too much unless it relates to the panic here.
:Couldn't get a dump because I didn't realize I hadn't specified a dumpdev (doh!).
I think the 'iterate entire history: unknown error: 0' was cockpit
trouble in the hammer ioctl code and not a real error. It was
fixed in 2.5.x.
The panic you got looks like it was an assertion instead of a
seg-fault, because the backtrace was btree->panic instead of
Methinks the panic message must have scrolled off the screen
(it would have been above the backtrace). The trap below the
trace was probably a double-fault in the debugger.
Definitely set up your dumpdev so we can get a dump if this
occurs for you again. There have been a couple of assertions
fixed in 2.5.x that have not been MFCd to 2.4.x due to the
HAMMER codebase diverging too much between 2.4.x and 2.5.x.
More information about the Bugs