Bug 592190 - No virt-manager debuginfo is available, so crashes in virt-manager refuse to be reported
Summary: No virt-manager debuginfo is available, so crashes in virt-manager refuse to ...
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-14 08:10 UTC by Justin Clift
Modified: 2011-06-27 16:21 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-27 16:21:20 UTC
Type: ---

Attachments (Terms of Use)
Screenshot of the error message in the Automatic Bug Reporting Tool. (122.18 KB, image/png)
2010-05-14 08:10 UTC, Justin Clift
no flags Details

Description Justin Clift 2010-05-14 08:10:05 UTC
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):


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.

Comment 1 Justin Clift 2010-05-14 08:10:45 UTC
Created attachment 413963 [details]
Screenshot of the error message in the Automatic Bug Reporting Tool.

Comment 2 Cole Robinson 2010-05-16 17:39:30 UTC
virt-manager is only python code, so doesn't have a debuginfo package. debuginfo-install should give you everything you need.

Comment 3 Justin Clift 2010-05-17 07:01:23 UTC
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.


Comment 4 Cole Robinson 2010-05-17 13:54:56 UTC
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.

Comment 5 Justin Clift 2010-05-17 14:22:22 UTC
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?

Comment 6 Bug Zapper 2011-06-02 14:03:35 UTC
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: 

Comment 7 Bug Zapper 2011-06-27 16:21:20 UTC
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.

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