This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 547365 - [abrt] crash detected in python-2.6.2-2.fc12
[abrt] crash detected in python-2.6.2-2.fc12
Status: CLOSED DUPLICATE of bug 540810
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Dave Malcolm
Fedora Extras Quality Assurance
abrt_hash:2baaf66b4d74c96e461af4e9fc1...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-14 08:52 EST by Robert Binkhorst
Modified: 2009-12-14 11:52 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-14 11:52:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (22.12 KB, text/plain)
2009-12-14 08:52 EST, Robert Binkhorst
no flags Details

  None (edit)
Description Robert Binkhorst 2009-12-14 08:52:37 EST
abrt 1.0.0 detected a crash.

How to reproduce
-----
1. Reboot, start virt-manager
2. Start 2 vm's at the "same" time by selecting the vm and clicking the start icon in virt-manager main window
3. Start another vm by double clicking on the name, followed by clicking on run from the new window.

Comment
-----
After a fresh reboot I started virt-manager, fired up 2 more virtual machines for some testing. I then started one more virtual machine, and virt-manager segfaulted after I clicked on run (I double clicked the machine name, and clicked run in the new window). This is the log file from the crash:
Dec 14 14:34:07 buffy kernel: device vnet3 entered promiscuous mode
Dec 14 14:34:07 buffy kernel: virbr0: topology change detected, propagating
Dec 14 14:34:07 buffy kernel: virbr0: port 4(vnet3) entering forwarding state
Dec 14 14:34:07 buffy NetworkManager: <WARN>  device_creator(): /sys/devices/virtual/net/vnet3: couldn't determine device driver; ignoring...

Last logs from the machine log in /var/log/libvirt/qemu is:
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc -m 256 -smp 1 -name rhel5-node1 -uuid 667d44b6-1683-a1a0-c195-453676b1ad39 -monitor unix:/var/lib/libvirt/qemu/rhel5-node1.monitor,server,nowait -boot c -drive file=/dev/vg_raid/lv_rhel5-node1,if=ide,index=0,boot=on -net nic,macaddr=54:52:00:76:48:da,vlan=0,name=nic.0 -net tap,fd=19,vlan=0,name=tap.0 -serial pty -parallel none -usb -vnc 127.0.0.1:3 -vga cirrus 
char device redirected to /dev/pts/15

After starting virt-manager again all vm's are still running but the machine started last, that one kernel-oopsed. If I double click the machine started last to open a new window and force shutdown that machine from that new window virt-manager crashes again. After that things seem to be back to normal, and the vm starts again from clicking start in it's own window. Virt-manager doesn't crash anymore.

I'm afraid I've not been able to repeat this so far...

Attached file: backtrace
cmdline: python /usr/share/virt-manager/virt-manager.py
component: python
executable: /usr/bin/python
kernel: 2.6.31.6-162.fc12.x86_64
package: python-2.6.2-2.fc12
rating: 3
reason: Process was terminated by signal 6
Comment 1 Robert Binkhorst 2009-12-14 08:52:41 EST
Created attachment 378213 [details]
File: backtrace
Comment 2 Dave Malcolm 2009-12-14 11:52:53 EST
Thank you for taking the time to file this bug report.

This particular bug has already been reported into our bug tracking system; I'm marking this one as a duplicate of that to try to help the virt-manager developers track this one down.

*** This bug has been marked as a duplicate of bug 540810 ***

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