Opened 16 years ago
Closed 16 years ago
#2538 closed bug (fixed)
PANIC: ASSERT FAILED (src/system/kernel/fs/vfs.cpp:799): oldRefCount > 0 while attempting to unmount partition
Reported by: | anevilyak | Owned by: | axeld |
---|---|---|---|
Priority: | high | Milestone: | R1/alpha1 |
Component: | System/Kernel | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Steps to reproduce:
- mount second BFS partition.
- cd to partition in a Terminal
- open DriveSetup
- attempt to unmount via DriveSetup (error -> busy)
- close Terminal
- attempt to unmount via DriveSetup (error -> busy)
- open Terminal and use Terminal unmount command -> KDL
vnode 0x90bb27f8 PANIC: ASSERT FAILED (src/system/kernel/fs/vfs.cpp:799): oldRefCount > 0 Welcome to Kernel Debugging Land... Running on CPU 0 kdebug> bt stack trace for thread 218 "unmount" kernel stack: 0x806c4000 to 0x806c8000 user stack: 0x7efef000 to 0x7ffef000 frame caller <image>:function + offset 0 806c7c14 (+ 32) 80052268 <kernel>:invoke_debugger_command + 0x00da 1 806c7c34 (+ 48) 8005236b <kernel>:invoke_pipe_segment(debugger_command_pipe*, long, char*) + 0x006f 2 806c7c64 (+ 32) 80052438 <kernel>:invoke_debugger_command_pipe + 0x008e 3 806c7c84 (+ 32) 80052f32 <kernel>:ExpressionParser::_ParseCommandPipe(int&) + 0x0084 4 806c7ca4 (+ 48) 80053516 <kernel>:ExpressionParser::EvaluateCommand(char const*, int&) + 0x010c 5 806c7cd4 (+ 192) 800535cf <kernel>:evaluate_debug_command + 0x0089 6 806c7d94 (+ 64) 800516ae <kernel>:kernel_debugger + 0x024c 7 806c7dd4 (+ 176) 80051795 <kernel>:panic + 0x002d 8 806c7e84 (+ 64) 80079ff7 <kernel>:dec_vnode_ref_count(vnode*, bool, bool) + 0x0057 9 806c7ec4 (+ 80) 8007dd72 <kernel>:fs_unmount(char*, long, unsigned long, bool) + 0x017c 10 806c7f14 (+ 48) 8007e11b <kernel>:_user_unmount + 0x006f 11 806c7f44 (+ 100) 800a0622 <kernel>:pre_syscall_debug_done + 0x0002 (nearest) iframe at 0x806c7fa8 (end = 0x806c8000) eax 0x50 ebx 0x2b1e00 ecx 0x7ffeeecc edx 0xffff0104 esi 0x7ffef5bc edi 0x7ffef544 ebp 0x7ffeeee8 esp 0x806c7fdc eip 0xffff0104 eflags 0x206 vector: 0x63, error code: 0x0 12 806c7fa8 (+ 0) ffff0104 13 7ffeeee8 (+ 128) 00200a10 <_APP_>:main + 0x00c8 14 7ffeef68 (+ 52) 002007fd <_APP_>:_start + 0x0051 15 7ffeef9c (+ 64) 0010019a 3526:runtime_loader_seg0ro@0x00100000 + 0x19a 16 7ffeefdc (+ 0) 7ffeefec 3525:unmount_main_stack@0x7efef000 + 0xffffec kdebug> vnode 0x90bb27f8 VNODE: 0x90bb27f8 device: 4 id: 2053 ref_count: -1 private_node: 0x90bb63fc mount: 0x90b08eb0 covered_by: 0x00000000 cache: 0x00000000 flags: --- advisory_lock: 0x00000000 kdebug> vnodes 4 address dev inode ref cache fs-node locking flags 0x90bb27f8 4 2053 -1 0x00000000 0x90bb63fc 0x00000000 --- 0x90bb2a18 4 2055 0 0x00000000 0x90bb694c 0x00000000 --- 0x90bb26e8 4 2119 0 0x00000000 0x90bb6aa0 0x00000000 --- 0x90bb2908 4 2251 0 0x00000000 0x90bb66a4 0x00000000 --- 0x90bb2fac 4 2276 0 0x00000000 0x90bbd2a8 0x00000000 --- 0x90bb2e58 4 2277 0 0x00000000 0x90bbd7f8 0x00000000 --- 0x90bb2d48 4 2278 0 0x00000000 0x90bbd550 0x00000000 --- 0x90bbb330 4 2273 0 0x00000000 0x90bbc154 0x00000000 --- 0x90bbb3fc 4 2274 0 0x00000000 0x90bbc3fc 0x00000000 --- 0x90bb2cc0 4 2275 0 0x00000000 0x90bbd3fc 0x00000000 --- 0x90bb2990 4 2284 0 0x00000000 0x90bb67f8 0x00000000 --- 0x90bbb264 4 2282 0 0x00000000 0x90bbde9c 0x00000000 --- 0x90bb2dd0 4 2283 0 0x00000000 0x90bbd6a4 0x00000000 --- 0x90bbb044 4 2332 0 0x00000000 0x90bb6e9c 0x00000000 --- 0x90bbb0cc 4 2370 0 0x00000000 0x90bbd000 0x00000000 --- 0x90bbb154 4 2449 0 0x00000000 0x90bbd154 0x00000000 --- 0x90bbb2ec 4 2476 0 0x90b371e0 0x90bbc000 0x00000000 --- 0x90bbb3b8 4 2477 0 0x90b3be10 0x90bbc2a8 0x00000000 --- 0x90bb2f24 4 2478 0 0x90b44870 0x90bbdaa0 0x00000000 --- 0x90bbb000 4 2484 0 0x90b40e10 0x90bbdbf4 0x00000000 --- 0x90bbb484 4 2488 0 0x90b60960 0x90bbc550 0x00000000 --- 0x90bb2c38 4 2581 0 0x00000000 0x90bb6d48 0x00000000 --- 0x90bb2ee0 4 2614 0 0x00000000 0x90bbd94c 0x00000000 --- 0x90bbb1dc 4 2647 0 0x00000000 0x90bbdd48 0x00000000 --- kdebug>
Change History (7)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
Could this be the culprit?
in fs_unmount: if ((flags & B_FORCE_UNMOUNT) == 0) { mutex_unlock(&sVnodeMutex); put_vnode(mount->root_vnode); return B_BUSY; } I don't see why it's doing put_vnode there, since it seems to release the ref as needed much earlier after checking the path, and I don't see any other obvious path that does this.
comment:3 by , 16 years ago
Yeah, that's more or less a "known" problem, already pointed out in bug #1982 I think. The attachment there got shreddered it seems though and before nobody had the time to really check the patch.
comment:4 by , 16 years ago
Ah, I didn't notice that one since a quick search didn't really match the kpanic description I'm hitting. Maybe the ASSERT was added later?
comment:5 by , 16 years ago
No, the assert was there once already, but only got reenabled recently. The message in bug #1988 pretty much matches this one, but the reason for the assert to fail is different in the case there. I think the observation is correct and would vote for removing the put_vnode() line. You could do so and test if the reference counting is correct then. If so, please feel free to commit the change.
This seems to be consistently reproducible by the way, the same set of steps crashes it both on my box and mmu_man's.