PANIC: cache destroy: still has partial slabs

[idefix]

(The outcome looks a lot like ticket:3180, but the cause is different)

After encountering bug #3048 again, I decided to boot into a recent Haiku installation (hrev34098) and check the volume:

~> mountvolume Build
Volume `Build' mounted successfully at '/Build'.
~> checkfs /Build/
checked 115475 nodes, 0 blocks not allocated, 0 blocks already set, 0 blocks could be freed
        files           91926
        directories     23520
        attributes      17
        attr. dirs      8
        indices         4
~> mountvolume -u Build

After 5 seconds I get into KDL:

PANIC: cache destroy: still has partial slabs
Welcome to Kernel Debugging Land...
Thread 208 "mountvolume" running on CPU 0
kdebug> bt
stack trace for thread 208 "mountvolume"
    kernel stack: 0x85268000 to 0x8526c000
      user stack: 0x7efef000 to 0x7ffef000
frame               caller     <image>:function + offset
 0 8526b9b8 (+  48) 800686e8   <kernel_x86> invoke_command_trampoline([34m0x8526ba50[0m) + 0x001c
 1 8526b9e8 (+  12) 800e0aa3   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 2 8526b9f4 (+  48) 800678c8   <kernel_x86>:debug_call_with_fault_handler + 0x0054
 3 8526ba24 (+  64) 80068941   <kernel_x86>:invoke_debugger_command + 0x00b9
 4 8526ba64 (+  64) 8006876d   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0x824ce030[0m, int32: [34m0[0m, [34m0x0[0m [31m"<NULL>"[0m) + 0x0079
 5 8526baa4 (+  64) 80068aac   <kernel_x86>:invoke_debugger_command_pipe + 0x009c
 6 8526bae4 (+  48) 8006a4a8   <kernel_x86> ExpressionParser<[32m0x8526bb94[0m>::_ParseCommandPipe([34m0x8526bb90[0m) + 0x0234
 7 8526bb14 (+  64) 800698e2   <kernel_x86> ExpressionParser<[32m0x8526bb94[0m>::EvaluateCommand([34m0x8012bcc0[0m [36m"bt"[0m, [34m0x8526bb90[0m) + 0x02ba
 8 8526bb54 (+ 224) 8006b8bc   <kernel_x86>:evaluate_debug_command + 0x0080
 9 8526bc34 (+  64) 8006645a   <kernel_x86> kernel_debugger_loop([34m0x8526bd14[0m [36m"cache destroy: still has partial slabs"[0m, int32: [34m0[0m) + 0x028e
10 8526bc74 (+  48) 800666ae   <kernel_x86> kernel_debugger_internal([34m0x8526bd14[0m [36m"cache destroy: still has partial slabs"[0m, int32: [34m0[0m) + 0x0042
11 8526bca4 (+  48) 80067a7f   <kernel_x86>:kernel_debugger + 0x0023
12 8526bcd4 (+ 192) 80067a51   <kernel_x86>:panic + 0x0029
13 8526bd94 (+  64) 800c2b87   <kernel_x86>:delete_object_cache + 0x0167
14 8526bdd4 (+  64) 8003068b   <kernel_x86>:_._11block_cache + 0x0043
15 8526be14 (+  48) 80033ca6   <kernel_x86>:block_cache_delete + 0x0162
16 8526be44 (+  64) 8057be60   <bfs> Volume<[32m0x8175e160[0m>::Unmount([34m0x81110000[0m) + 0x00e4
17 8526be84 (+  48) 8057cf68   <bfs> bfs_unmount(fs_volume*: [34m0x81118618[0m) + 0x0024
18 8526beb4 (+  80) 800adb74   <kernel_x86> fs_unmount([34m0x83a49000[0m [36m"/Build"[0m, int32: [34m-1[0m, uint32: [34m0x0[0m ([34m0[0m), [34mfalse[0m) + 0x0484
19 8526bf04 (+  64) 800af6d6   <kernel_x86>:_user_unmount + 0x007a
20 8526bf44 (+ 100) 800e1082   <kernel_x86>:handle_syscall + 0x00af
user iframe at 0x8526bfa8 (end = 0x8526c000)
 eax 0x58           ebx 0x587be4        ecx 0x7ffee750   edx 0xffff0114
 esi 0x7ffee800     edi 0x1802f0a0      ebp 0x7ffee77c   esp 0x8526bfdc
 eip 0xffff0114  eflags 0x207      user esp 0x7ffee750
 vector: 0x63, error code: 0x0
21 8526bfa8 (+   0) ffff0114   <commpage>:commpage_syscall + 0x0004
22 7ffee77c (+ 160) 003d8303   <libbe.so> BPartition<[32m0x1802f0a0[0m>::Unmount(uint32: [34m0x0[0m ([34m0[0m)) + 0x0087
23 7ffee81c (+ 112) 002077d0   <_APP_> MountVisitor<[32m0x7ffeeb64[0m>::Visit(BPartition*: [34m0x1802f0a0[0m, int32: [34m1[0m) + 0x0550
24 7ffee88c (+  48) 003d2d29   <libbe.so> BPrivate::PartitionFilterVisitor<[32m0x7ffee9ec[0m>::Visit(BPartition*: [34m0x1802f0a0[0m, int32: [34m1[0m) + 0x0059
25 7ffee8bc (+  48) 003d9c54   <libbe.so> BPartition<[32m0x1802f0a0[0m>::_AcceptVisitor(BDiskDeviceVisitor*: [34m0x7ffee9ec[0m, int32: [34m1[0m) + 0x0030
26 7ffee8ec (+  48) 003d9ca7   <libbe.so> BPartition<[32m0x1802f0a0[0m>::_VisitEachDescendant(BDiskDeviceVisitor*: [34m0x7ffee9ec[0m, int32: [34m1[0m) + 0x0047
27 7ffee91c (+  48) 003d9cdd   <libbe.so> BPartition<[32m0x1802f0e0[0m>::_VisitEachDescendant(BDiskDeviceVisitor*: [34m0x7ffee9ec[0m, int32: [34m0[0m) + 0x007d
28 7ffee94c (+  48) 003d873b   <libbe.so> BPartition<[32m0x1802f0e0[0m>::VisitEachDescendant(BPartition: [34m0x7ffee9ec[0m, BDiskDeviceVisitor*: [34m0x7ffee9bc[0m) + 0x002f
29 7ffee97c (+  48) 003d1c51   <libbe.so> BDiskDeviceList<[32m0x7ffeeaf8[0m>::VisitEachPartition(BDiskDeviceVisitor*: [34m0x7ffee9ec[0m) + 0x0049
30 7ffee9ac (+  80) 003d1e09   <libbe.so> BDiskDeviceList<[32m0x7ffeeaf8[0m>::VisitEachMountablePartition(BDiskDeviceVisitor*: [34m0x7ffeeb64[0m) + 0x004d
31 7ffee9fc (+ 400) 002053cb   <_APP_> MountVolume<[32m0x7ffeee74[0m>::ArgvReceived(int32: [34m3[0m, [34m0x18029190[0m [36m"¨&#8216;pp&#8216;``&#8216;""[0m) + 0x06f7
32 7ffeeb8c (+  64) 002c1830   <libbe.so> BApplication<[32m0x7ffeee74[0m>::_ArgvReceived(BMessage*: [34m0x1801ab90[0m) + 0x0114
33 7ffeebcc (+ 496) 002bfe7c   <libbe.so> BApplication<[32m0x7ffeee74[0m>::DispatchMessage(BMessage*: [34m0x1801ab90[0m, BHandler*: [34m0x7ffeee74[0m) + 0x00c8
34 7ffeedbc (+  64) 002cb161   <libbe.so> BLooper<[32m0x7ffeee74[0m>::task_looper([34m0x7ffeee74[0m) + 0x0211
35 7ffeedfc (+  64) 002be925   <libbe.so> BApplication<[32m0x7ffeee74[0m>::Run([34m0x120004[0m) + 0x0075
36 7ffeee3c (+ 320) 00205eab   <_APP_>:main + 0x002f
37 7ffeef7c (+  48) 002047d3   <_APP_>:_start + 0x005b
38 7ffeefac (+  48) 00105b1a   </boot/system/runtime_loader@0x00100000>:unknown + 0x5b1a
39 7ffeefdc (+   0) 7ffeefec   4972:mountvolume_main_stack@0x7efef000 + 0xffffec
kdebug> continue

After this, everything looks normal (the terminal outputs Volume `Build' unmounted successfully.) apart from one thing:

[idefix]

ProcessController showing high memory usage

[idefix]

It looks like changeset:35918 also fixed this bug.

I can't reproduce it on hrev35923, while I could on hrev35914. (And my system is much more responsive while checkfs is running.)

[bonefish]

Indeed. Thanks for the update!