Project

General

Profile

Actions

Bug #1672

open

panic (trap 12) around btree_search() in 2.4.1-RELEASE

Added by floid about 14 years ago. Updated about 9 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
VFS subsystem
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Using 2.4.1 with the lone patch from http://bugs.dragonflybsd.org/issue1583

DragonFly tucker 2.4.1-RELEASE DragonFly v2.4.1.40.ga038d-RELEASE #1: Sat Jan 30
11:57:51 EST 2010 root@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!).

db> trace
Debugger(c0591d40) at Debugger+0x34
panic(c0576343,c059e4c3,c055d984,11,4000) at panic+0x9f
btree_search(d6df38e4,d6df3880,c0483897,d6df38e4,d6df38e4) at btree_search+0x14a
hammer_btree_lookup(d6df38e4) at hammer_btree_lookup+0xd9
hammer_btree_first(d6df38e4,c04ad0a7,19792,15,22) at hammer_btree_first+0xd
hammer_ioc_rebalance(d6df3a74,d684cdd0,c294ed50,f4240,0) at hammer_ioc_rebalanca
hammer_ioctl(d684cdd0,c0c0680f,c294ed50,1,c28a6b28) at hammer_ioctl+0x726
hammer_vop_ioctl(d6df3ad0,c06409c0,d2f80d50,d2f8dc50,0) at hammer_vop_ioctl+0x2f
vop_ioctl(d2f80d50,c2a12e28,c0c0680f,c294ed50,1) at vop_ioctl+0x3e
vn_ioctl(cfe75b40,c0c0680f,c294ed50,c28a6b28,d6df3cf0) at vn_ioctl+0xe0
mapped_ioctl(4,c0c0680f,bfbff88c,0,d6df3cf0) at mapped_ioctl+0x3e7
sys_ioctl(d6df3cf0,6,0,0,d268c6d8) at sys_ioctl+0x17
syscall2(d6df3d40) at syscall2+0x1ef
Xint0x80_syscall() at Xint0x80_syscall+0x36

Task map 0xc0514cec: pmap=0x1e2, nentries=1946206313, version=12061300

Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x8300c08a
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04a5608
stack pointer = 0x10:0xd6df359c
frame pointer = 0x10:0xd6df35a8
code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 19689 (hammer)
current thread = pri 42 (CRIT)

kernel: type 12 trap, code=0
Stopped at Debugger+0x34: movb $0,in_Debugger.4260

Actions #1

Updated by dillon about 14 years ago

:New submission from Joe "Floid" Kanowitz <>:
:
:Using 2.4.1 with the lone patch from http://bugs.dragonflybsd.org/issue1583
:
:DragonFly tucker 2.4.1-RELEASE DragonFly v2.4.1.40.ga038d-RELEASE #1: Sat Jan 30
:11:57:51 EST 2010 root@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!).
:
:db> trace
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
btree->trap->panic.
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.
-Matt
Actions #2

Updated by floid about 14 years ago

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.

I'm still learning my way around the debugger - this is that 'production'
machine set up with a serial console and I only drape the cable across the room
when it acts up. The 'trap below' was from an intentional show command, pardon
any ambiguity.

What's the right way to retrieve the actual panic string after you've entered
ddb? Or is there none? [The msgbuf didn't seem to have it.]

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.

Yup, set up properly now.

Actions #3

Updated by dillon about 14 years ago

:What's the right way to retrieve the actual panic string after you've entered
:ddb? Or is there none? [The msgbuf didn't seem to have it.]

It should have it above the stack backtrace.  It may have scrolled
off. With a video console you can use scroll lock and cursor up.
With a serial console whatever terminal program you have it in...
well, like tip or cu inside an xterm, use the scroll bar on the xterm
to scroll up.
-Matt
Matthew Dillon
&lt;&gt;
Actions #4

Updated by floid about 14 years ago

With a serial console whatever terminal program you have it in...
well, like tip or cu inside an xterm, use the scroll bar on the xterm
to scroll up.

That's the rub, for various spatial reasons a 'terminal' is physically not
connected most of the time. After the annoyance of not being able to see it
today (and trying to 'cheat') I'm thinking of digging out an extension cable [or
switching 'properly' to unattended mode].

Actions #5

Updated by tuxillo about 9 years ago

  • Description updated (diff)
  • Category set to VFS subsystem
  • Status changed from New to Feedback
  • Assignee deleted (0)
  • Target version set to Unverifiable

Moving to unverifiable.
Feel free to update it if you can reproduce it.

Cheers,
Antonio Huete

Actions

Also available in: Atom PDF