Opened 8 years ago

Closed 19 months ago

Last modified 3 months ago

#8405 closed bug (not reproducible)

PANIC: rw_lock_read_unlock(): lock 0xcdf21664 not read-locked

Reported by: humdinger Owned by: nobody
Priority: normal Milestone:
Component: System/Kernel Version: R1/Development
Keywords: locking Cc:
Blocked By: Blocking:
Platform: All


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 (1)

KDL.JPG (125.9 KB ) - added by humdinger 8 years ago.
KDL: rw_lock_read_unlock()

Download all attachments as: .zip

Change History (9)

by humdinger, 8 years ago

Attachment: KDL.JPG added

KDL: rw_lock_read_unlock()

comment:1 by anevilyak, 8 years ago

Component: System/KernelFile Systems/BFS

comment:2 by axeld, 8 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, 8 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, 8 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, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:6 by humdinger, 19 months ago

Cannot remember ever having seen this one again. Close?

comment:7 by waddlesplash, 19 months ago

Resolution: not reproducible
Status: assignedclosed

comment:8 by nielx, 3 months ago

Milestone: R1

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

Note: See TracTickets for help on using tickets.