Opened 10 years ago

Last modified 3 weeks ago

#4223 assigned bug

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

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

Description

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 10 years ago.
mountvolume.txt (673 bytes) - added by jonas.kirilla 10 years ago.
mountvolume_KPartition_deadbeef.txt (2.2 KB) - added by jonas.kirilla 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 10 years ago by jonas.kirilla

Attachment: mountvolume_kdl.txt added

Changed 10 years ago by jonas.kirilla

Attachment: mountvolume.txt added

comment:1 Changed 10 years ago by jonas.kirilla

mountvolume.txt is from hrev32305

Lines of interest in mountvolume.cpp:

http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#459 http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#476

http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#192 http://haiku.it.su.se:8180/source/xref/src/bin/mountvolume.cpp#195

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 Changed 10 years ago by axeld

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 Changed 10 years ago by axeld

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

comment:4 Changed 10 years ago by jonas.kirilla

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 Changed 9 years ago by anevilyak

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.

Changed 9 years ago by jonas.kirilla

comment:6 Changed 9 years ago by jonas.kirilla

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 Changed 9 years ago by jonas.kirilla

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 Changed 9 years ago by axeld

Blocking: 4833 added

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

comment:9 Changed 23 months ago by axeld

Owner: changed from axeld to nobody
Status: newassigned

comment:10 Changed 3 weeks ago by waddlesplash

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

Note: See TracTickets for help on using tickets.