DragonFly bugs List (threaded) for 2009-11
[Date Prev][
Date Next]
[Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
panic: assertion: parent != NULL in hammer_cursor_removed_node (Re: panic: assertion: leaf->base.obj_id == ip->obj_id in hammer_ip_delete_range)
On Sat, Oct 31, 2009 at 07:54:07PM +0900, YONETANI Tomokazu wrote:
> > :> :$ panic: assertion: parent != NULL in hammer_cursor_removed_node
> > :> :mp_lock = 00000000; cpuid = 0
> > :> :Trace beginning at frame 0x5b7dfabc
> > :> :panic(5b7dfae0,0,0,58ba7168,5b7dfaf8) at 0x80dadce
> > :> :panic(824684c,8269077,82826b7,5e226588,0) at 0x80dadce
> > :> :hammer_cursor_removed_node(58ba7168,0,0,5b7dfc9c,0) at 0x81fe93a
> > :> :hammer_btree_do_propagation(58ba7168,0,58ba71b8,58ba71b8,58ba71b8) at 0x81fc4e0
> > :> :hammer_btree_do_propagation(0,0,52e22040,b,5b7dfbe8) at 0x81fc4c5
> > :> :hammer_btree_delete(5b7dfc9c,1,1,5b7d0114,52e22040) at 0x81fc8c4
(NOTE: the original panic mentioned in the Subject: line hasn't bitten me
for a while, but the new panic in hammer_cursor_removed_node is)
> Hmm... currently I'm running vkernel built from source as of
> e4eb09b2 (that is, hammer06.patch unapplied), and I can't reproduce
> the panic on this kernel. I'm compiling vkernel from f3a4893b0
> and see if I can reproduce this panic again.
Although my /usr/obj on vkernel no longer triggers the panic,
mirror-write'ing to a slave then pfs-destroy'ing it can still trigger
the panic. It's not necessarily the same panic triggered by removing
my /usr/obj followed by a sync, but at least it's reproducible.
I believe that the following results eliminate the possiblity of bad
compiler causing the panic:
vkernel from e4eb09b2 built on Oct 22 world(PC): no panic
vkernel from e4eb09b2 built on Oct 31 world(vkernel): no panic
vkernel from f3a4893b built on Oct 22 world(PC): panic
vkernel from f3a4893b built on Oct 31 world(vkernel): panic
Matt, can you determine if the situation is one of the following?
Because I'm not sure how to validate the mirror-stream data:
A) the mirror-stream data is somehow corrupted, and f3a4893b0 caught
something that e4eb09b2 missed
B) f3a4893b has introduced a new bug not existed in e4eb09b2
I've put the mirror-stream image which can trigger the panic
on my leaf account, as ~y0netan1/crash/usr.src.hammer.gz.
Its shared-uuid is c7d03096-4ce7-11de-85c5-0108543c929d.
# cd /pfs
# hammer pfs-slave test shared-uuid=c7d03096-4ce7-11de-85c5-0108543c929d
# zcat ~y0netan1/crash/usr.src.hammer.gz | hammer mirror-write
# hammer pfs-destroy
[Date Prev][
Date Next]
[Thread Prev][
Thread Next]
[
Date Index][
Thread Index]