Red Hat Bugzilla – Bug 979546
virt-manager sometimes gets into an entirely stuck state after selecting an ISO to attach to a VM
Last modified: 2016-09-30 11:17:37 EDT
This is nowhere close to 100% reproducible, but it happens often enough to annoy me. I use v-m heavily, changing ISOs frequently, and when we're in a validation cycle I hit this maybe once every day or two. What happens is this: I want to attach an ISO to a VM (almost always a Fedora image of some kind), so I go to 'IDE CDROM 1', click 'Disconnect' if something's already there, click 'Connect', leave 'ISO Image Location' selected, and hit Browse... The GNOME file chooser pops up. I pick some ISO (doesn't seem to matter whether I have to browse around before doing it, or I'm already in the right directory; I'm pretty sure I've seen the bug in both cases), hit 'OK' (or whatever the button's labelled) - I think I usually click, I don't press enter - and the file chooser closes. Now I'm back at virt-manager's 'Choose Media' dialog, but the Browse..., Cancel and OK buttons are all greyed out. At this point virt-manager appears to be entirely stuck, I have not found any way to recover. I wind up just clicking the X on the VM window (the Choose Media dialog doesn't have one) and using GNOME's 'app is not responding, force quit?' dialog to kill it. The v-m debug output has nothing helpful, all I get is this: 2013-06-28 11:42:35,604 (choosecd:70): Showing media chooser 2013-06-28 11:42:36,364 (storagebrowse:82): Showing storage browser 2013-06-28 11:42:36,968 (config:545): directory for type=isomedia returning=/share/data/isos/17 2013-06-28 11:42:38,846 (config:553): saving directory for type=media to /share/data/isos/17 2013-06-28 11:42:38,847 (storagebrowse:88): Closing storage browser Last time it happened I attached gdb to the process and got a backtrace out with v-m in its stuck state. I'll attach that.
Created attachment 766710 [details] backtrace from the stuck virt-manager
I'm currently on virt-manager-0.10.0-1.fc19.noarch but I'm pretty sure I was seeing this long before that particular build. I went from 0.9.5 to 0.10.0-0.1.gitd3f9bc8e.fc19.noarch on April 30th; I can't recall if that's when the bug started happening, but it may be.
Note that /share/data is a CIFS share from my NAS box (on the same network), and my desktop is a pretty stock F19 GNOME 3.
Adam, are you still seeing this?
I've been on vacation for the last few weeks, just got back. I'm up to latest F20 on my desktop, I'll keep an eye out and see if this still happens.
Just happened to me again, host is current F20, virt-manager-0.10.0-2.git948b5359.fc20.noarch .
While I haven't reproduced, I fixed upstream to not be so tricky with dialog modality. So I'll attach this bug to the next build, but take it out of ON_QA or reopen it if you can still reproduce
virt-manager-0.10.0-4.git79196cdf.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/virt-manager-0.10.0-4.git79196cdf.fc20
Package virt-manager-0.10.0-4.git79196cdf.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-4.git79196cdf.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18473/virt-manager-0.10.0-4.git79196cdf.fc20 then log in and leave karma (feedback).
crobinso: roger - note I'm away from my main testing rig atm, though. I don't do anywhere near as much VM work when I'm stuck on the laptop, so it's *less* likely I'l run into this until I'm back home in a couple weeks, even if it is still happening. just FYI. I'll adjust as necessary if it happens to show up again, of course.
virt-manager-0.10.0-4.git79196cdf.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Just saw this again, with virt-manager-0.10.0-5.git1ffcc0cc.fc20.noarch :( It certainly hasn't been happening as much as it used to, though, this is the first time I remember seeing it since the bug was closed.
Seem this a few more times lately in Rawhide, I'm afraid. Twice tonight.
just saw this again on F21 (virt-manager-1.0.1-3.fc21.1.noarch ), it hasn't gone away yet :( I hadn't seen it for a while though, it seems to be rarer with F21.
Seen this lately adam?
not often, maybe once since 07-18. it may be related to debug kernels, possibly?
Aaand indeed, it's happening again to me fairly frequently now i'm back on post-F21 Rawhide. Seems regular as clockwork - it happens quite a lot pre-Alpha, much less common after that. But the current Rawhide kernels aren't debug ones, so I've no idea what's going on, *why* it seems to happen so much more often in this period of the cycle...
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
adam are you still seeing this? (sorry that's all I keep asking, I still don't know what the issue is...)
still pretty much the same story, it still mysteriously seems to happen more when I'm running Rawhide between one release and the Branching of the next, *even when I'm running a nodebug kernel*. Which still makes no goddamn sense, but it's what happens. Every time I say 'well, if it doesn't happen again next post-release time I'll close it', and every time it still freaking happens. It's bizarre. Once again, I'm seeing it very rarely if at all right now, but we're in a Branched phase. Once again, I'll check it when I'm running Rawhide after 23 comes out. :/
I'll make a note to try a debug kernel sometime. Could be some race condition in gtk or x that triggers with nested modal dialogs
Okay, I ran kernel-debug and tried to reproduce with a dogtail script, but no luck. I tried two variants - using a win2k12 guest, repeatedly disconnect the cdrom, click 'connect' to open the cdrom chooser, click 'browse' to open the storage browser, select a different iso from the default pool, choose 'open volume', click 'ok', wait a bit, continue at 'disconnect' - simpler loop just launching the storage browser, selecting a different iso, hitting 'open volume', wait a bit, launch browser again, etc. I also changed the code to create a new storage browser dialog on every invocation, while the current code will reuse the previously created dialog, but it didn't trigger. So, a few questions for the next time this triggers: - How many libvirt connections are open in virt-manager? - How many VMs are on those connections? - How many are running? - How many of the running ones have you graphically connected to previously from this virt-manager instance? - When the issue reproduces, what sequence of media change was this: * First since running the app * First for this particular VM * First since starting the VM * something else Also some more debugging info to grab. Install python-debuginfo, and when the app hangs, connect with gdb and collect - info threads - thread apply all bt - thread apply all py-bt - thread apply all py-list Might also then be interesting to let the app spin some more, interrupt it with gdb again, do those traces and see if anything changed. And again after clicking the window 'X' to close the app via gnome-shell's app-is-hung message, connect with gdb and check the traces
it's that time again :) adam did you see this during the f24 dev cycle ?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
For the record, I don't think I saw this yet during F25.
(In reply to Adam Williamson from comment #25) > For the record, I don't think I saw this yet during F25. are you using wayland? I wonder if it's an X thing
good guess, but nah, I'm still on X till https://bugzilla.gnome.org/show_bug.cgi?id=758958 gets fixed.