abrt 1.0.3 detected a crash. How to reproduce ----- 1. Add an IDE disk (partition) to a running guest while the partition is mounted on the host. virt-manager complains: keep for later sessions. 2. Unmount the partition from the host. Comment: Not sure it's the problem: it just occurred for the 1st time. But the above is what I was doing at this time. Attached file: backtrace cmdline: libvirtd --daemon component: libvirt executable: /usr/sbin/libvirtd kernel: 2.6.31.9-174.fc12.x86_64 package: libvirt-0.7.1-15.fc12 rating: 4 reason: Process was terminated by signal 11 (Segmentation fault)
Created attachment 385399 [details] File: backtrace
This thread in the stack trace is the interestnig one. Notice how 'group=0x0' - we have a NULL pointer de-reference here causing a SEGV. I don't think we've seen this particular crash before either. Thread 1 (Thread 1833): #0 0x00000000004367e2 in virCgroupPathOfController (group=0x0, controller=<value optimized out>, key=0x46b14b "devices.deny", path=0x7f3f2a64b918) at cgroup.c:242 No locals. #1 0x0000000000436a8c in virCgroupSetValueStr (group=<value optimized out>, controller=<value optimized out>, key=<value optimized out>, value=0x7f3f1c0008e0 "b 8:17 rwm") at cgroup.c:267 rc = 0 keypath = 0x0 __func__ = "virCgroupSetValueStr" #2 0x0000000000436d84 in virCgroupDenyDevice (group=0x0, type=<value optimized out>, major=711244056, minor=0) at cgroup.c:824 rc = <value optimized out> devstr = 0x7f3f1c0008e0 "b 8:17 rwm" #3 0x0000000000436f81 in virCgroupDenyDevicePath (group=0x0, path=<value optimized out>) at cgroup.c:873 sb = {st_dev = 16, st_ino = 6067, st_nlink = 1, st_mode = 25008, st_uid = 107, st_gid = 107, __pad0 = 0, st_rdev = 2065, st_size = 0, st_blksize = 4096, st_blocks = 0, st_atim = { tv_sec = 1263895657, tv_nsec = 61160235}, st_mtim = { tv_sec = 1263767156, tv_nsec = 127475968}, st_ctim = { tv_sec = 1263905050, tv_nsec = 541255067}, __unused = {0, 0, 0}} #4 0x000000000042e2db in qemudDomainAttachDevice (dom=<value optimized out>, xml=<value optimized out>) at qemu_driver.c:5894 driver = <value optimized out> vm = <value optimized out> dev = 0x7f3f1c09a8f0 qemuCmdFlags = 1047934 cgroup = 0x0 ret = -1 __FUNCTION__ = "qemudDomainAttachDevice" __func__ = "qemudDomainAttachDevice" Do you have any cgroups mounted (check /proc/mounts for any FS of type 'cgroup') ?
> Do you have any cgroups mounted (check /proc/mounts for any FS of type 'cgroup') ? No Some more info: _ I reproduced the crash once again while the partition was not mounted on the host and the guest was running: the crash occurred immediately when finishing the (unsuccessful) disk addition. _ I finally succeeded adding this disk after shutting down the guest. _ Host: F12 x86-64; guest: F10 i386. _ There is another guest running: F12 x86-64. I did not stop it to succeed.
Same problem on acting the same way on the F12 x86-64 guest. The constant is: "add an IDE drive (using the GUI) to a running guest crashes libvirtd"
Seems to be fixed upstream, though I didn't track down the actual commit. We can easily fix this with: diff -rup libvirt-0.7.1/src/qemu_driver.c new/src/qemu_driver.c --- libvirt-0.7.1/src/qemu_driver.c>2010-06-03 13:51:14.398483000 -0400 +++ new/src/qemu_driver.c>..2010-06-03 13:56:05.667092000 -0400 @@ -5988,7 +5988,7 @@ static int qemudDomainAttachDevice(virDo virDomainDiskDeviceTypeToString(dev->data.disk->device)); /* Fallthrough */ } - if (ret != 0) { + if (ret != 0 && cgroup) { virCgroupDenyDevicePath(cgroup, dev->data.disk->src); }
libvirt-0.7.1-18.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libvirt-0.7.1-18.fc12
libvirt-0.7.1-18.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libvirt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libvirt-0.7.1-18.fc12
libvirt-0.7.1-18.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.