Opened 15 years ago
Closed 15 years ago
#5415 closed bug (fixed)
Block cache: ASSERT: (/home/bonefish/develop/haiku/haiku/src/system/kernel/cache/block_cache.cpp:1025): block->CanBeWritten()
Reported by: | bonefish | Owned by: | axeld |
---|---|---|---|
Priority: | high | Milestone: | R1 |
Component: | System/Kernel | Version: | R1/Development |
Keywords: | Cc: | Jens.Arm@… | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
hrev35490, gcc4 hybrid
Assert triggered by "rm -rf objects" in my test "generated" directory.
PANIC: ASSERT FAILED (/home/bonefish/develop/haiku/haiku/src/system/kernel/cache/block_cache.cpp:1025): block->CanBeWritten() Welcome to Kernel Debugging Land... Thread 437 "rm" running on CPU 7 kdebug> bt stack trace for thread 437 "rm" kernel stack: 0x80891000 to 0x80895000 user stack: 0x7efef000 to 0x7ffef000 frame caller <image>:function + offset 0 80894708 (+ 32) 8006e159 <kernel_x86> invoke_command_trampoline(void*: 0x80894788) + 0x0015 1 80894728 (+ 12) 800e171c <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b 2 80894734 (+ 48) 8006c04e <kernel_x86>:debug_call_with_fault_handler + 0x0051 3 80894764 (+ 64) 8006e4d6 <kernel_x86>:invoke_debugger_command + 0x00bb 4 808947a4 (+ 48) 8006e5f3 <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80134622, int32: 0, char*: NULL) + 0x0083 5 808947d4 (+ 32) 8006e6bb <kernel_x86>:invoke_debugger_command_pipe + 0x008b 6 808947f4 (+ 128) 80072446 <kernel_x86> ExpressionParser<0x808948c4>::_ParseCommandPipe(int&: 0x808948c0) + 0x0aae 7 80894874 (+ 48) 80074c0f <kernel_x86> ExpressionParser<0x808948c4>::EvaluateCommand(char const*: 0x80134620 "bt", int&: 0x808948c0) + 0x06df 8 808948a4 (+ 192) 80074d88 <kernel_x86>:evaluate_debug_command + 0x0084 9 80894964 (+ 96) 8006ce21 <kernel_x86> kernel_debugger_internal(char const*: 0x81fa06c0 "", int32: -2138486288) + 0x039a 10 808949c4 (+ 16) 8006cf77 <kernel_x86>:kernel_debugger + 0x0019 11 808949d4 (+ 160) 8006d039 <kernel_x86>:panic + 0x002a 12 80894a74 (+ 48) 8003bbc2 <kernel_x86> BlockWriter<0x80894ad8>::Add(cached_block*: 0x81fa06c0) + 0x0034 13 80894aa4 (+ 144) 8003c753 <kernel_x86> write_cached_block(block_cache*: 0xccd16050, cached_block*: 0xcd93b110, true) + 0x0025 14 80894b34 (+ 160) 8003c9f7 <kernel_x86>:cache_end_transaction + 0x0130 15 80894bd4 (+ 304) 809c500c <bfs> Journal<0xce541000>::_WriteTransactionToLog() + 0x09dc 16 80894d04 (+ 48) 809c5131 <bfs> Journal<0xce541000>::_TransactionDone(true) + 0x00db 17 80894d34 (+ 48) 809c5e5c <bfs> Journal<0xce541000>::Unlock(Transaction*: 0x80894dcc, true) + 0x0054 18 80894d64 (+ 32) 809b34ff <bfs> Transaction<0x80894dcc>::Done() + 0x002b 19 80894d84 (+ 112) 809cd729 <bfs> bfs_unlink(fs_volume*: 0x8204a258, fs_vnode*: 0x820db8c4, char const*: 0x80894e1c "IconRenderer.o") + 0x00d5 20 80894df4 (+ 304) 800aeb64 <kernel_x86> common_unlink(int32: 1025, char*: 0x828528c0, true) + 0x0050 21 80894f24 (+ 32) 800aec01 <kernel_x86>:_user_unlink + 0x007f 22 80894f44 (+ 100) 800e1cf2 <kernel_x86>:handle_syscall + 0x00af user iframe at 0x80894fa8 (end = 0x80895000) eax 0x6e ebx 0x2d4d28 ecx 0x7ffee93c edx 0xffff0114 esi 0x0 edi 0x0 ebp 0x7ffee958 esp 0x80894fdc eip 0xffff0114 eflags 0x216 user esp 0x7ffee93c vector: 0x63, error code: 0x0 23 80894fa8 (+ 0) ffff0114 <commpage>:commpage_syscall + 0x0004 24 7ffee958 (+ 576) 00207661 <_APP_>:unlinkat + 0x01c1 25 7ffeeb98 (+ 64) 00203cc0 <_APP_>:main (nearest) + 0x1048 26 7ffeebd8 (+ 448) 002049b4 <_APP_>:main (nearest) + 0x1d3c 27 7ffeed98 (+ 288) 00205825 <_APP_>:rm + 0x0191 28 7ffeeeb8 (+ 176) 002030f0 <_APP_>:main + 0x0478 29 7ffeef68 (+ 52) 002029ad <_APP_>:_start + 0x0051 30 7ffeef9c (+ 64) 00105367 </boot/system/runtime_loader@0x00100000>:unknown + 0x5367 31 7ffeefdc (+ 0) 7ffeefec 4394:rm_main_stack@0x7efef000 + 0xffffec
Change History (6)
comment:1 by , 15 years ago
Cc: | added |
---|
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Status: | new → in-progress |
---|
comment:5 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I've forgotten one situation when fixing this one; IOW it can still happen.
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Should be fixed in hrev35565.
Note:
See TracTickets
for help on using tickets.
Interesting one. Besides that I obviously forgot to let cache_end_transaction() use the BlockWriter directly, this shouldn't really happen.
I so far did not manage to reproduce this bug, but I've added some more debug capabilities in hrev35493. I assume that the block mentioned as argument to BlockWriter::Add() is not the block that is actually added, but that one mentioned in the write_cached_block() line. If someone comes across this bug again, the output of "cached_block <address>" would give further insight.