Description of problem: When using virt-manager on F13, connected to a RHEL 6 beta host server, virt-manager crashed. After it took some time to collect a backtrace and attempt to process it, the Automatic Bug Reporting Tool came up and took details. However, it has a warning message and won't allow a bug to be reported using it: Please fix the following problems * Reporting disabled because the backtrace is unusable. Please try to install debuginfo manually using command: debuginfo-install virt-manager then use Refresh button to regenerate the backtrace. After looking into the missing debuginfo package, it turns out the virt-manager doesn't have one at all. This likely means that problems in virt-manager (such as this crash) are going unreported. Version-Release number of selected component (if applicable): virt-manager-0.8.3-3.fc13.noarch How reproducible: This crash has only occurred once, the very first time I've attempted to use virt-manager from this F13 desktop to a RHEL 6 beta server. Steps to Reproduce: 1. While connected to the remote RHEL 6 beta x86_64 server, begin the process of creating a new vm. 2. Go through all of the settings. Choices made were: 1 CPU, 512MB RAM, 1x 20GB iSCSI LUN (already mapped on host), RHEL 6 beta x86_64 ISO file NFS shared to the remote host, 1x network connection using NAT through eth0 on the remote host. 3. This crash occurs immediately after virt-manager has collected the above info, then attempts to create the new vm. 4. The "Automatic Bug Reporting Tool" window then appears, which doesn't allow bug submission. Actual results: Bug report is unable to be submitted. Expected results: Bug report to be at least submitted, possibly leaving out the "unusable" backtrace. Additional info: Screenshot attached in case it's helpful.
Created attachment 413963 [details] Screenshot of the error message in the Automatic Bug Reporting Tool.
virt-manager is only python code, so doesn't have a debuginfo package. debuginfo-install should give you everything you need.
Heh, good thought, but not sure I agree. (btw debuginfo-install doesn't help in this situation as no debug package exists, as you've mentioned) Btw, I'm more inclined to think there's a bug still here. Maybe in the ABRT stuff, as perhaps it should be adjusted to ignore crashes in python code? If that's the correct approach. It just seems a bit silly for the Abrt gui to kick in after a crash, then it turns out to not actually be able to do anything. It probably shouldn't kick in then. ?
debuginfo-install will give debuginfos for all packages that are dependencies of the specified package. In this case, that will be debuginfo for gtk, gobject, various X libraries, etc, even though virt-manager itself doesn't have debuginfo. And even though virt-manager is written in python, it is using plenty of C code (python itself, gtk, etc.) that can core dump, so abrt seems like it is correct here. If debuginfo-install isn't returning anything, my guess is either all the debuginfos are installed, or something is wrong with your repos. abrt could be messing up and deeming the backtrace as unusable when it isn't. FYI, the crash you are seeing is fixed in the latest gtk-vnc package, so a yum update should fix it.
Yeah, the abrt GUI is refusing to do a report purely because there isn't a virt-manager debuginfo. (as per screenshot.) See the "Send report" is greyed out? Looks like a bug in the abrt gui. I've just changed the Bugzilla component this is reported on to be "abrt". Guessing you'll need to re-assign it to someone else now?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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. Thank you for reporting this bug and we are sorry it could not be fixed.