Re: Re: panic: assertion: leaf->base.obj_id == ip->obj_id in hammer_ip_delete_range

[YONETANI Tomokazu <qhwt+dfly@xxxxxxxxxx>]

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
>     why.
> 
>     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
>     patches.

the backtrace should actually look like this (confirmed this by inserting
kprintf's here and there):
hammer_cursor_removed_node
btree_remove
btree_remove
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.