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.
