Bug 979546 - virt-manager sometimes gets into an entirely stuck state after selecting an ISO to attach to a VM
virt-manager sometimes gets into an entirely stuck state after selecting an I...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
22
All All
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-28 15:49 EDT by Adam Williamson
Modified: 2016-09-30 11:17 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 06:15:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backtrace from the stuck virt-manager (30.78 KB, text/plain)
2013-06-28 15:51 EDT, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2013-06-28 15:49:43 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.
Comment 1 Adam Williamson 2013-06-28 15:51:38 EDT
Created attachment 766710 [details]
backtrace from the stuck virt-manager
Comment 2 Adam Williamson 2013-06-28 15:53:33 EDT
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.
Comment 3 Adam Williamson 2013-06-28 15:54:23 EDT
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.
Comment 4 Cole Robinson 2013-08-31 13:10:13 EDT
Adam, are you still seeing this?
Comment 5 Adam Williamson 2013-09-17 20:22:47 EDT
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.
Comment 6 Adam Williamson 2013-09-25 01:41:38 EDT
Just happened to me again, host is current F20, virt-manager-0.10.0-2.git948b5359.fc20.noarch .
Comment 7 Cole Robinson 2013-10-06 15:36:29 EDT
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
Comment 8 Fedora Update System 2013-10-06 16:00:58 EDT
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
Comment 9 Fedora Update System 2013-10-07 11:47:37 EDT
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).
Comment 10 Adam Williamson 2013-10-07 15:14:52 EDT
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.
Comment 11 Fedora Update System 2013-10-15 02:34:24 EDT
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.
Comment 12 Adam Williamson 2013-11-19 13:33:53 EST
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.
Comment 13 Adam Williamson 2014-01-30 00:36:08 EST
Seem this a few more times lately in Rawhide, I'm afraid. Twice tonight.
Comment 14 Adam Williamson 2014-07-18 17:37:04 EDT
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.
Comment 15 Cole Robinson 2014-09-20 19:44:19 EDT
Seen this lately adam?
Comment 16 Adam Williamson 2014-09-26 00:22:50 EDT
not often, maybe once since 07-18. it may be related to debug kernels, possibly?
Comment 17 Adam Williamson 2015-01-09 17:38:46 EST
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...
Comment 18 Jaroslav Reznik 2015-03-03 09:58:08 EST
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
Comment 19 Cole Robinson 2015-09-24 16:27:31 EDT
adam are you still seeing this?

(sorry that's all I keep asking, I still don't know what the issue is...)
Comment 20 Adam Williamson 2015-09-24 16:33:16 EDT
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. :/
Comment 21 Cole Robinson 2015-09-24 16:35:16 EDT
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
Comment 22 Cole Robinson 2015-11-05 21:11:03 EST
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
Comment 23 Cole Robinson 2016-06-17 13:38:37 EDT
it's that time again :) adam did you see this during the f24 dev cycle ?
Comment 24 Fedora End Of Life 2016-07-19 06:15:05 EDT
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.
Comment 25 Adam Williamson 2016-09-19 09:57:07 EDT
For the record, I don't think I saw this yet during F25.
Comment 26 Cole Robinson 2016-09-30 10:20:06 EDT
(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
Comment 27 Adam Williamson 2016-09-30 11:17:37 EDT
good guess, but nah, I'm still on X till https://bugzilla.gnome.org/show_bug.cgi?id=758958 gets fixed.

Note You need to log in before you can comment on or make changes to this bug.