On Mon, Feb 11, 2013 at 02:02:21PM +0000, Richard W.M. Jones wrote:
This seems to be some sort of deadlock, easily reproduced by running the libguestfs test suite, or even just 'libguestfs-test-tool'.
Here is a stack trace:
(gdb) t a a bt
Thread 8 (Thread 0x7fe64edd4700 (LWP 20024)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 ---Type <return> to continue, or q <return> to quit--- #1 0x000000328ca09ca6 in _L_lock_836 () from /lib64/libpthread.so.0 #2 0x000000328ca09ba8 in __GI___pthread_mutex_lock ( mutex=mutex@entry=0x7fe64006eb30) at pthread_mutex_lock.c:64 #3 0x00007fe650ad142d in virMutexLock (m=m@entry=0x7fe64006eb30) at util/virthreadpthread.c:85 #4 0x00007fe650ac38de in virObjectLock (anyobj=anyobj@entry=0x7fe64006eb20) at util/virobject.c:322 #5 0x00007fe650ce65b1 in virSecurityManagerGetModel ( mgr=mgr@entry=0x7fe64006eb20) at security/security_manager.c:236 #6 0x00007fe650ce994c in virSecuritySELinuxSecurityVerify ( mgr=0x7fe64006eb20, def=<optimized out>) at security/security_selinux.c:1806 #7 0x00007fe650ce7251 in virSecurityManagerVerify (mgr=0x7fe64006eb20, def=def@entry=0x7fe63400ac20) at security/security_manager.c:573 #8 0x00007fe650ce3cd4 in virSecurityStackVerify (mgr=<optimized out>, def=0x7fe63400ac20) at security/security_stack.c:125 #9 0x00007fe650ce7251 in virSecurityManagerVerify (mgr=0x7fe64001cc50, def=def@entry=0x7fe63400ac20) at security/security_manager.c:573
This shows the problem - the security driver implementations are not allowed to call back out to other virSecurityManagerXXX APis like virSecurityManagerGetModel, since that causes recursive mutex acquisition. I've cc'd you on a fix Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|