#5878: [I/O Scheduler] rw_lock_read_unlock(): lock not read-locked ---------------------------+------------------------------------------------ Reporter: damoklas | Owner: axeld Type: bug | Status: new Priority: normal | Milestone: R1/alpha2 Component: System/Kernel | Version: R1/Development Keywords: | Blockedby: Platform: All | Blocking: ---------------------------+------------------------------------------------ Comment(by bonefish): So far things look OK. My analysis so far: - The outer IORequest is a read at offset 0, size 4096. - The request is passed to bfs_io(), which read-locks the vnode and passes the request on to do_iterative_fd_io(). - do_iterative_fd_io() creates a subrequest via do_iterative_fd_io_iterate(). The subrequest is only 2048 bytes long and the outer request is only advanced that far, which means that BFS's iterative_io_get_vecs_hook() returned only a single vector of this size. The file is obviously <= 2 KB in size. - The subrequest is satisfied by the I/O scheduler, its NotifyFinished() is invoked with B_OK and it calls the parent request's SubRequestFinished() with status = B_OK, partialTransfer = false, and transferEndOffset = 2048. - SubRequestFinished() determines that this is the last pending subrequest and calls NotifyFinished(B_OK). Since the subrequest succeeded fully, the request's fPartialTransfer remains false. - NotifyFinished() determines the request as not yet fully finished (fStatus == B_OK && !fPartialTransfer && RemainingBytes() > 0). Hence it calls the iteration callback to get more subrequests. iterative_io_get_vecs_hook() cannot get any vectors and thus returns B_OK and _partialTransfer = true. Therefore the request's fPartialTransfer is set to true and NotifyFinished() falls through to actually finish the request. - The finished callback, do_iterative_fd_io_finish(), is called, which in turn calls BFS's iterative_io_finished_hook() that read-unlocks the vnode. For some reason the vnode has already been unlocked at that point, which triggers the panic(). I've added an assert to ensure that NotifyRequest() is not called twice in r36594 (trunk). damoklas, when you encounter it again, could do the following, please: - Execute {{{io_request}}} as before. {{{io_request_owner}}} won't be needed. - The {{{io_request}}} prints a line with {{{thread:}}} and the number of the responsible thread (''104'' in screenshot you attached). Run {{{bt <thread>}}} (replace {{{<thread>}}} by the thread number) to print a stack trace for that thread. The output might be longer and overwrite the previous one, so better take a screenshot before. Thanks! -- Ticket URL: <http://dev.haiku-os.org/ticket/5878#comment:5> Haiku <http://dev.haiku-os.org> Haiku - the operating system.