[haiku-bugs] Re: [Haiku] #3159: [kernel] PANIC: ASSERT FAILED: vnode->ref_count ==0 && vnode->busy

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Sun, 18 Mar 2012 17:41:25 -0000

#3159: [kernel] PANIC: ASSERT FAILED: vnode->ref_count ==0 && vnode->busy
   Reporter:  diver          |      Owner:  axeld
       Type:  bug            |     Status:  new
   Priority:  normal         |  Milestone:  R1
  Component:  System/Kernel  |    Version:  R1/Development
 Resolution:                 |   Keywords:
 Blocked By:                 |   Blocking:  8402
Has a Patch:  0              |   Platform:  All

Comment (by bonefish):

 I still haven't got a better idea what goes wrong here. Of the two assert
 conditions the busy condition should hold, since `remove_vnode()`
 explicitly sets the vnode to busy before calling `free_vnode()`. That
 leaves the ref count. `remove_vnode()` only frees nodes that haven't been
 published before and only `new_vnode()` creates a vnode that is not
 published yet. The created vnode has ref count 1 and is busy. Due to the
 latter `get_vnode()` cannot be called (respectively would hang). So at
 least via this method the ref count cannot be increased, which is why
 `remove_vnode()` expects it to be 0 after decrementing.

 There are a few other code paths that directly increment a vnode ref
 count, but skimming through those I don't really see any that would be
 executed in this situation. A quick look at the BFS code doesn't reveal
 any interesting stuff besides the `new_vnode()` and `remove_vnode()`
 calls, but I haven't checked what is called indirectly. Maybe Axel has an

 For debugging purposes I think it would be worthwhile to force an error in
 the BFS code and see whether it triggers the KDL. If so, it shouldn't be
 hard to track down the issue.

Ticket URL: <http://dev.haiku-os.org/ticket/3159#comment:5>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: