DragonFly bugs List (threaded) for 2009-11
Re: Re: panic: assertion: leaf->base.obj_id == ip->obj_id in hammer_ip_delete_range
On Mon, Nov 02, 2009 at 09:04:32PM -0800, Matthew Dillon wrote:
> :On Thu, Oct 22, 2009 at 06:19:01PM -0700, Matthew Dillon wrote:
> :> fetch http://apollo.backplane.com/DFlyMisc/hammer06.patch
> :It seems like btree_remove() sets cursor->parent to NULL in its
> :recursion path starting at hammer_btree.c:2226 but somehow returns 0
> :which ends up hitting the first KKASSERT() in hammer_cursor_removed_node().
Duh. I THOUGHT I saw the same panic message in vmcore.11, but now I
checked that again and it turned out the same with vmcore.10 and not
with the vkernel one. Sorry about the confusion.
> In your vkernel panic. By the way, the panic message will be correct
> but the symbols in the backtrace are clearly messed up. For some
> reason the vkernel reports the symbols incorrectly, I don't know
> But given that panic message:
> panic: assertion: parent != NULL in hammer_cursor_removed_node
> The only possible path is via btree_remove(). I'm a bit at a loss
> here. I don't see how that panic could still occur with the recent
the backtrace should actually look like this (confirmed this by inserting
kprintf's here and there):
hammer_btree_delete(5c865738,5c865738,5,5c865a0c,52b17040) at 0x81fcb6a
hammer_delete_at_cursor(5c865738,2,0,0,4af05332) at 0x820ba90
The hammer_cursor_removed_node() is called right after returning from
the third recursion to btree_remove(), which calls hammer_cursor_up()
at the bottom of it. hammer_cursor_up(), when called with a non-NULL
cursor->parent, assigns cursor->parent to cursor->node, then calls
hammer_load_cursor_parent(). This function sets cursor->parent to NULL
and returns 0 when called with cursor->node->ondisk->parent == 0, that is,
when cursor->parent->ondisk->parent == 0 in the third btree_remove().
> I went through your emails again and found this comment:
> "By the way, I caught a different panic on vkernel. I think the last
> I ran `hammer cleanup' on /usr/obj was before applying hammer05.patch
> or hammer06.patch to vkernel."
> Was that vkernel backtrace a pre-patch panic?
The backtrace was from the vkernel with hammer6.patch applied.