Description of problem: Attempting to start virt-manager. Version-Release number of selected component: virt-manager-0.10.0-5.git1ffcc0cc.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/bin/python /usr/share/virt-manager/virt-manager crash_function: elf_machine_rela executable: /usr/bin/python2.7 kernel: 3.13.3-201.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 elf_machine_rela at ../sysdeps/x86_64/dl-machine.h:276 #1 elf_dynamic_do_Rela at do-rel.h:137 #2 _dl_relocate_object at dl-reloc.c:294 #3 dl_open_worker at dl-open.c:416 #4 _dl_catch_error at dl-error.c:177 #5 _dl_open at dl-open.c:650 #6 dlopen_doit at dlopen.c:66 #7 _dl_catch_error at dl-error.c:177 #8 _dlerror_run at dlerror.c:163 #9 __dlopen at dlopen.c:87
Created attachment 866836 [details] File: backtrace
Created attachment 866837 [details] File: cgroup
Created attachment 866838 [details] File: core_backtrace
Created attachment 866839 [details] File: dso_list
Created attachment 866840 [details] File: environ
Created attachment 866841 [details] File: exploitable
Created attachment 866842 [details] File: limits
Created attachment 866843 [details] File: maps
Created attachment 866844 [details] File: open_fds
Created attachment 866845 [details] File: proc_pid_status
Created attachment 866846 [details] File: var_log_messages
This is strange, coming from dlopen which makes it very unlikely that this is specific to virt-manager. Is this reproducible? When does it fail, at app bootup?
This is 100% repeatable. virt-manager never fully starts up. You get the segfault before you see anything. A bit of further information. The machine is a thinkpad t530, it was upgraded from f19 to f20 (with virt-manager working fine on f19). 2 vms which worked fine under f19. (graphics are locked to intel; nouveau is not loading).
What's rpm -qa | grep libvirt ?
[phlap@wagner ~]$ rpm -qa | grep libvirt libvirt-daemon-driver-qemu-1.1.3.3-5.fc20.x86_64 libvirt-client-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-lxc-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-storage-1.1.3.3-5.fc20.x86_64 libvirt-daemon-qemu-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-xen-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.3-5.fc20.x86_64 libvirt-daemon-config-nwfilter-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-uml-1.1.3.3-5.fc20.x86_64 libvirt-daemon-config-network-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-secret-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-network-1.1.3.3-5.fc20.x86_64 libvirt-python-1.1.3.3-5.fc20.x86_64 libvirt-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-interface-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-nodedev-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-vbox-1.1.3.3-5.fc20.x86_64 libvirt-daemon-driver-libxl-1.1.3.3-5.fc20.x86_64 libvirt-daemon-kvm-1.1.3.3-5.fc20.x86_64 libvirt-daemon-1.1.3.3-5.fc20.x86_64 libvirt-glib-0.1.7-2.fc20.x86_64 [phlap@wagner ~]$
Peter, please make sure the system is fully up to date, there's a newer libvirt at least but it may not fix this. Moving to glibc. I see there's a similar trace with glibc bug #1046601, but that user has nvidia drivers installed. Doesn't seem to be the case here. There's also a few other bugs with similar traces: inkscape: https://bugzilla.redhat.com/show_bug.cgi?id=1033450 system-config-services: https://bugzilla.redhat.com/show_bug.cgi?id=1047560
Updated, and problem still there.
(In reply to Peter Howard from comment #17) > Updated, and problem still there. Can you provide a core file for this?
Created attachment 870727 [details] Core dump
Core dump in comment 19
I've managed to manually resolve this. It was related to libvirtd failing to start, with missing dynamic library dependencies. From ldd: libwsman_client.so.2 => not found libwsman_client.so.2 => not found libwsman_client.so.2 => not found Which _should_ come from libswman1. rpm showed 2 copies: rpm -q libwsman1 libwsman1-2.3.6-8.fc20.x86_64 libwsman1-2.4.3-1.fc20.x86_64 Then: sudo rpm -e libwsman1-2.3.6-8.fc20.x86_64 sudo yum reinstall libwsman1 provided the missing libraries. So I'm not sure whether there's anything you want to chase here, or whether this should just be closed.
(In reply to Peter Howard from comment #21) > I've managed to manually resolve this. It was related to libvirtd failing > to start, with missing dynamic library dependencies. From ldd: ... > So I'm not sure whether there's anything you want to chase here, or whether > this should just be closed. There is. We should never have gotten to a crash, it should have been detected as a missing dependency. Why wasn't it? How was this DSO loaded? All of this should have either been an immediate abort at startup or dlopen returning failure. Can you dig a bit deeper now that you know what the cause was? We want a sensible error message in this case.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.