[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
idea.
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:
