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

[humdinger]

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...

[humdinger]

KDL: rw_lock_read_unlock()

[axeld]

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.

[bonefish]

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.

[humdinger]

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.

[humdinger]

Cannot remember ever having seen this one again. Close?

[nielx]

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

[bbjimmy]

on hrev57498 x86_64 I just got the same kdl.

[bbjimmy]

kdl with backtrace

[bbjimmy]

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> 

[bbjimmy]

I just got this kdl again on hrev57615

identical kdl and backtrace.

[waddlesplash]

bbjimmy, does this only ever happen on one machine for you?

[bbjimmy]

Replying to waddlesplash:

bbjimmy, does this only ever happen on one machine for you?

It has only happened on one computer (the other one is running beta 4 ).

[bbjimmy]

Twice in one day on hrev87753!

[bbjimmy]

Kdl with backtrace

[waddlesplash]

Please retest with a recent nightly (hrev58111+). If it still happens, I will see about preparing a rwlock-asserts build for you to test with; though such builds use a somewhat different I/O path through BFS and may not encounter the problem...

[waddlesplash]

Fixed in hrev58351.