Description of problem: Not sure, I think it happened after waking from suspend-to-RAM. Version-Release number of selected component: virt-manager-0.10.0-4.fc19 Additional info: reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: /usr/bin/python /usr/share/virt-manager/virt-manager crash_function: virFree executable: /usr/bin/python2.7 kernel: 3.11.10-200.fc19.x86_64 runlevel: N 5 type: CCpp uid: 1000 var_log_messages: Dec 16 04:26:14 fe abrt-hook-ccpp[5265]: Saved core dump of pid 4979 (/usr/bin/python2.7) to /var/tmp/abrt/ccpp-2013-12-16-04:26:13-4979 (291069952 bytes) Truncated backtrace: Thread no. 1 (10 frames) #1 virFree at util/viralloc.c:443 #2 virResetError at util/virerror.c:348 #3 virCopyError at util/virerror.c:180 #4 virDispatchError at util/virerror.c:590 #5 virDomainDestroyFlags at libvirt.c:2310 #6 shutdown_libvirt at launch-libvirt.c:1646 #7 child_cleanup at proto.c:98 #8 recv_from_daemon at proto.c:520 #9 guestfs___recv_from_daemon at proto.c:611 #10 guestfs___recv at proto.c:654
Created attachment 837242 [details] File: backtrace
Created attachment 837243 [details] File: cgroup
Created attachment 837244 [details] File: core_backtrace
Created attachment 837245 [details] File: dso_list
Created attachment 837246 [details] File: environ
Created attachment 837247 [details] File: exploitable
Created attachment 837248 [details] File: limits
Created attachment 837249 [details] File: maps
Created attachment 837250 [details] File: open_fds
Created attachment 837251 [details] File: proc_pid_status
Strange, coming from libguestfs, but not sure what could cause it
It is more directly coming from libvirt. However the confounding factor is that libguestfs is (in another thread) forking a process, and libguestfs is not especially careful about not mallocing along forking paths, which is of course a Bad Thing. (https://bugzilla.redhat.com/show_bug.cgi?id=115429#c4) libvirt guys: Can you have a careful look at the stack traces: https://bugzilla.redhat.com/attachment.cgi?id=837242 and bounce it back to me if you think it's a malloc/fork error.
On the other hand, libvirt is calling free (mem=0x336463342d316338) where that pointer doesn't look like a pointer, but does look a bit like an ASCII string "3dc4-1c8".
If it had anything to do with libguestfs, then most likely it would be because of https://bugzilla.redhat.com/show_bug.cgi?id=790837. Note that exit has been called and there is an atexit handler (close_handles) running.
17:30 < danpb> thread 5 shows #7 0x00000038578a3989 in guestfs___recursive_remove_dir (g=g@entry=0x7f1ef403a4e0, dir=0x7f1ef40090b0 "/tmp/libguestfsdEgSOt") at tmpdirs.c:157 17:30 < danpb> thread 1 shows #6 0x0000003857898dd3 in shutdown_libvirt (g=0x7f1ef403a4e0, check_for_errors=<optimized out>) at launch-libvirt.c:1646 17:30 < danpb> in both cases you have g=0x7f1ef403a4e0 It looks as if we've already closed the libvirt handle in one thread, while trying to close it a second time in another thread. In any case the way to fix this is to use: guestfs.GuestFS (close_on_exit = False)
Patch posted: https://www.redhat.com/archives/virt-tools-list/2013-December/msg00030.html
Fixed in virt-manager upstream. https://git.fedorahosted.org/cgit/virt-manager.git/commit/?id=006fcd38562707377f99cf029a25ade8f88738b7
Bug fixed in less than five hours after being reported? I'm seriously impressed:) Thank you!