Opened 12 years ago
Last modified 3 months ago
#8405 reopened bug
PANIC: rw_lock_read_unlock(): lock 0xcdf21664 not read-locked
Reported by: | humdinger | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | File Systems/BFS | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is hrev43873 gcc2hybrid.
I got the attached KDL that I haven't seen before. BeShare and Vision were running, while BeZilla was loading a few quite large images. So large in fact, that the system even became a bit unresponsive. Before I could take a look at the memory consumption etc. I took off to KDL...
Attachments (2)
Change History (15)
by , 12 years ago
comment:1 by , 12 years ago
Component: | System/Kernel → File Systems/BFS |
---|
comment:2 by , 12 years ago
Component: | File Systems/BFS → System/Kernel |
---|
This looks awfully similar to #2557 - I wonder if bonefish missed a few cases :-) In any case, this is most likely not a BFS bug; I'll change components again.
comment:3 by , 12 years ago
The do_iterative_fd_io()
code is rather straight forward. Unless it falls back to synchronous IO (which it didn't in this case) it never calls the finished hook directly (only via IORequest::SetStatusAndNotify()
and only when do_iterative_fd_io_iterate()
fails). So one would think the only possibility for the BFS finished hook to be called twice is that IORequest::NotifyFinished()
is called twice. Which is a bit puzzling, since that method sports an ASSERT(!fIsNotified)
that would be triggered in that case (fIsNotified
is only set there and isn't reset anywhere).
An alternative explanation would be that the BFS finished hook is not called twice, but that something has happened to the Inode
object in the meantime (deleted, overwritten).
In either event more information is needed: The last part of the syslog (just in case BFS logged oddities), an io_request ...
for the I/O request (the parameter to iterative_io_finished_hook()
), an io_request_owner ...
for its owner, and a stack trace for owning thread.
comment:4 by , 12 years ago
The syslog from then is long gone... I'll have a look should I encounter that one again. But as I said, I haven't had one of those ever, so it might not come up for me again.
comment:5 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 5 years ago
Resolution: | → not reproducible |
---|---|
Status: | assigned → closed |
comment:8 by , 4 years ago
Milestone: | R1 |
---|
Remove milestone for tickets with status = closed and resolution != fixed
comment:10 by , 4 months ago
Resolution: | not reproducible |
---|---|
Status: | closed → reopened |
comment:11 by , 4 months ago
Component: | System/Kernel → File Systems/BFS |
---|---|
Keywords: | locking removed |
comment:12 by , 4 months ago
I can't find anything interesting in the syslogs, but I got this running checkfs:
Welcome to the Haiku shell. ~/Desktop> checkfs /boot 54110 nodes checked, 0 blocks not allocated, 0 blocks already set, 9888 blocks could be freed files 39156 directories 12884 attributes 1072 attr. dirs 942 indices 56 direct block runs 62899 (19.13 GiB) indirect block runs 2012 (in 237 array blocks, 21.81 GiB) double indirect block runs 0 (in 0 array blocks, 0 bytes) ~/Desktop>
KDL: rw_lock_read_unlock()