Opened 11 years ago

Closed 13 months ago

Last modified 4 months ago

#4223 closed bug (not reproducible)

KDL on use of /bin/mountvolume (and multiple images)

Reported by: jonas.kirilla Owned by: nobody
Priority: normal Milestone:
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #4833
Platform: All


I was trying capture the output of /bin/mountvolume (having restarted Tracker in a Terminal) to show what mountvolume prints when launched on 10 images and it fails to mount some of them, when Haiku KDL:ed. Two consecutive tries resulted in a KDL.

Attachments (3)

mountvolume_kdl.txt (2.3 KB ) - added by jonas.kirilla 11 years ago.
mountvolume.txt (673 bytes ) - added by jonas.kirilla 11 years ago.
mountvolume_KPartition_deadbeef.txt (2.2 KB ) - added by jonas.kirilla 11 years ago.

Download all attachments as: .zip

Change History (15)

by jonas.kirilla, 11 years ago

Attachment: mountvolume_kdl.txt added

by jonas.kirilla, 11 years ago

Attachment: mountvolume.txt added

comment:1 by jonas.kirilla, 11 years ago

mountvolume.txt is from hrev32305

Lines of interest in mountvolume.cpp:

Today I've had no crash yet, but Tracker, Deskbar and Terminal hung (on filesystem access?) after having tried the same mountvolume thing.

comment:2 by axeld, 11 years ago

So far, I could only reproduce the hang (which is a dead lock in the disk device manager's device watcher).

Have you used the "force unmount" feature while trying to reproduce this bug?

comment:3 by axeld, 11 years ago

The dead lock should be fixed in hrev32526. I've seen the crash now, too, without having force unmounted anything.

comment:4 by jonas.kirilla, 11 years ago

Thanks, I will try it out soon.

I don't think I tried force unmounting. The hang or crash would happen on opening the images via Tracker (and so having them mounted by mountvolume). When the images -did- mount successfully I don't think I ever had any problem unmounting. (Either by selecting the volume(s) and pressing Alt-U, or opening the image(s) again (having mountvolume unmount it/them.)

comment:5 by anevilyak, 11 years ago

Just a note, hrev32526 had a regression in it that was fixed in hrev32820. Please review to ensure it doesn't reintroduce the deadlock, though as far as I can tell it should be safe.

by jonas.kirilla, 11 years ago

comment:6 by jonas.kirilla, 11 years ago

With hrev32822/trunk two sessions of testing (out of two) have ended in KDL. See attachment. I haven't seen a deadlock with this revision.

Procedure: I create 8 images sized 20MB on the desktop, using dd if=/dev/zero, format these as BFS using mkfs, select all 8 images and start pressing Alt-O repeatedly. This will mount and unmount all 8 images. If you repeat Alt-O too fast it crashes. This is with SMP.

comment:7 by jonas.kirilla, 11 years ago

Repeating the above procedure (but with hrev32822/r1alpha1 on a single-cpu box) results in a bunch of mountvolume threads stuck in the kernel. One mountvolume thread holds the vfs_mount_op_lock and the other ones are waiting for it. The thread that holds the lock has a zzz(zzz) state(next state), sigpending 0x100000 (blocked 0x0) and waiting for: snooze().

comment:8 by axeld, 11 years ago

Blocking: 4833 added

(In #4833) The hang is probably a duplicate of #4223. Please alway only mention one bug per ticket.

comment:9 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:10 by waddlesplash, 19 months ago

Anyone seen or managed to reproduce this since 9 years ago?

comment:11 by waddlesplash, 13 months ago

Resolution: not reproducible
Status: assignedclosed

comment:12 by nielx, 4 months ago

Milestone: R1

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

Note: See TracTickets for help on using tickets.