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)

KDL.JPG (125.9 KB ) - added by humdinger 12 years ago.
KDL: rw_lock_read_unlock()
kdl_and_bactrace.png (3.3 MB ) - added by bbjimmy 4 months ago.
kdl with backtrace

Change History (15)

by humdinger, 12 years ago

Attachment: KDL.JPG added

KDL: rw_lock_read_unlock()

comment:1 by anevilyak, 12 years ago

Component: System/KernelFile Systems/BFS

comment:2 by axeld, 12 years ago

Component: File Systems/BFSSystem/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 bonefish, 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 humdinger, 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 axeld, 7 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:6 by humdinger, 5 years ago

Cannot remember ever having seen this one again. Close?

comment:7 by waddlesplash, 5 years ago

Resolution: not reproducible
Status: assignedclosed

comment:8 by nielx, 4 years ago

Milestone: R1

Remove milestone for tickets with status = closed and resolution != fixed

comment:9 by bbjimmy, 4 months ago

on hrev57498 x86_64 I just got the same kdl.

by bbjimmy, 4 months ago

Attachment: kdl_and_bactrace.png added

kdl with backtrace

comment:10 by waddlesplash, 4 months ago

Resolution: not reproducible
Status: closedreopened

comment:11 by waddlesplash, 4 months ago

Component: System/KernelFile Systems/BFS
Keywords: locking removed

comment:12 by bbjimmy, 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> 






comment:13 by bbjimmy, 3 months ago

I just got this kdl again on hrev57615

identical kdl and backtrace.

Last edited 3 months ago by bbjimmy (previous) (diff)
Note: See TracTickets for help on using tickets.