Bug 580816 - libvirt: crash when shutting down a VM
Summary: libvirt: crash when shutting down a VM
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 13
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-09 06:47 UTC by Xudong Yang
Modified: 2010-05-18 17:23 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-05-18 17:23:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Xudong Yang 2010-04-09 06:47:19 UTC
Description of problem:
While shutting down a virtual machine, Virtual Machine Manager crashes because libvirtd crashed unexpectedly.

Version-Release number of selected component (if applicable):
libvirt-0.7.7-1.fc13(x86_64)

How reproducible:
Unknown
  
Actual results:
Virtual Machine Manager and libvirtd crashed when shutting down a virtual machine.

Expected results:
Virtual machine shut down successfully with Virtual Machine Manager runs normally.

Additional info:
Here are relevant log messages:

Apr  9 14:18:06 dhcp-65-66 kernel: br0: port 2(vnet0) entering disabled state
Apr  9 14:18:06 dhcp-65-66 libvirtd: 14:18:06.475: error : interfaceListInterfaces:208 : internal error failed to list host interfaces (netcf: unspecified error - errors in loading some config files)
Apr  9 14:18:06 dhcp-65-66 kernel: libvirtd[1692]: segfault at fffffff7 ip 0000003eddc7ded1 sp 00007ff288e32a90 error 4 in libc-2.11.90.so[3eddc00000+17c000]
Apr  9 14:18:06 dhcp-65-66 kernel: device vnet0 left promiscuous mode
Apr  9 14:18:06 dhcp-65-66 kernel: br0: port 2(vnet0) entering disabled state
Apr  9 14:18:06 dhcp-65-66 avahi-daemon[1435]: Withdrawing address record for fe80::3031:c7ff:fe6b:11bd on vnet1.
Apr  9 14:18:06 dhcp-65-66 kernel: virbr0: port 1(vnet1) entering disabled state
Apr  9 14:18:06 dhcp-65-66 kernel: device vnet1 left promiscuous mode
Apr  9 14:18:06 dhcp-65-66 kernel: virbr0: port 1(vnet1) entering disabled state
Apr  9 14:18:08 dhcp-65-66 abrt[5954]: saved core dump of pid 1686 (/usr/sbin/libvirtd) to /var/cache/abrt/ccpp-1270793886-1686.new/coredump (90386432 bytes)

After it crashes, use
# service libvirtd restart
command restart the daemon successfully.

Comment 1 Daniel Berrangé 2010-04-09 10:16:38 UTC
Can you do

 debuginfo-install libvirt

and then capture a trace with GDB. If you're not familiar with GDB, the following will hopefully do the job

 $ gdb /usr/sbin/libvirtd /var/cache/abrt/ccpp-1270793886-1686.new/coredump
 (gdb) thread apply all backtrace

Comment 2 Xudong Yang 2010-04-15 01:14:44 UTC
Here is the result


Program terminated with signal 11, Segmentation fault.
#0  0x0000003eddc7ded1 in free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install libvirt-0.7.7-1.fc13.x86_64
(gdb) thread apply all backtrace

Thread 7 (Thread 1691):
#0  0x0000003ede00b7ec in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000042d456 in virCondWait ()
#2  0x00000000004172f5 in getpwuid_r ()
#3  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
#4  0x0000003eddce4b3d in clone () from /lib64/libc.so.6

Thread 6 (Thread 1690):
#0  0x0000003ede00b7ec in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000042d456 in virCondWait ()
#2  0x00000000004172f5 in getpwuid_r ()
#3  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
#4  0x0000003eddce4b3d in clone () from /lib64/libc.so.6

Thread 5 (Thread 1689):
#0  0x0000003ede00b7ec in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000042d456 in virCondWait ()
#2  0x00000000004172f5 in getpwuid_r ()
#3  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#4  0x0000003eddce4b3d in clone () from /lib64/libc.so.6

Thread 4 (Thread 1687):
#0  0x0000003eddcdb423 in poll () from /lib64/libc.so.6
#1  0x0000000000414455 in getpwuid_r ()
#2  0x00000000004163c9 in getpwuid_r ()
#3  0x00000000004166a3 in getpwuid_r ()
#4  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
#5  0x0000003eddce4b3d in clone () from /lib64/libc.so.6

Thread 3 (Thread 1688):
#0  0x0000003ede00b7ec in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x000000000042d456 in virCondWait ()
#2  0x00000000004172f5 in getpwuid_r ()
#3  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
#4  0x0000003eddce4b3d in clone () from /lib64/libc.so.6

Thread 2 (Thread 1686):
#0  0x0000003ede0080ed in pthread_join () from /lib64/libpthread.so.0
#1  0x000000000041a41b in getpwuid_r ()
#2  0x0000003eddc1ed2d in __libc_start_main () from /lib64/libc.so.6
#3  0x00000000004134a9 in getpwuid_r ()
---Type <return> to continue, or q <return> to quit---
#4  0x00007fffb4574188 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000002 in ?? ()
#7  0x00007fffb4575ec9 in ?? ()
#8  0x00007fffb4575ed2 in ?? ()
#9  0x0000000000000000 in ?? ()

Thread 1 (Thread 1692):
#0  0x0000003eddc7ded1 in free () from /lib64/libc.so.6
#1  0x000000000042d29c in virFree ()
#2  0x000000000041c5cb in getpwuid_r ()
#3  0x00000000004244e1 in getpwuid_r ()
#4  0x0000000000424893 in getpwuid_r ()
#5  0x0000000000417388 in getpwuid_r ()
#6  0x0000003ede007861 in start_thread () from /lib64/libpthread.so.0
#7  0x0000003eddce4b3d in clone () from /lib64/libc.so.6


Hope this would help.

Comment 3 Cole Robinson 2010-05-18 17:23:36 UTC
This backtrace looks messed up, not really sure what to do to fix it.

Can you reliably reproduce with the latest packages in F13? If so, please either paste the backtrace that abrt shows you, or as root run the following:

1) service libvirtd stop
2) gdb libvirtd
3) At gdb prompt, type 'run'
4) Reproduce the issue in another terminal
5) At gdb prompt, type 'thread apply all bt'

I'm assuming this isn't reliably reproducable, so closing as WORKSFORME. Please reopen with the above info if you are still seeing this.


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