Red Hat Bugzilla – Bug 512350
Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Last modified: 2010-03-16 13:22:08 EDT
Description of problem:
I'm using libvirt's python wrapper and get into lots of trouble when having concurrent TLS connections (to xen://localhost/). I assume that is the bug in gnutls which is described on the Internet:
Version-Release number of selected component (if applicable):
libvirt-0.6.4 (from Debian lenny stable repo)
Always, makes libvirt unusable for me
Steps to Reproduce:
Create two concurrent connections to xen://localhost/, e.g. using multithreading (and yes, global locks did *not* help, it's really a gnutls problem) and use the connection somehow. In my test case thread A was getting domain information and thread B was to shutdown a domain.
The following errors occur and the python process is aborted immediately:
python: ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed
Simultaneous TLS connections should not crash the application.
As to the links given above (especially http://lists.gnupg.org/pipermail/gcrypt-devel/2006-January/000911.html), it might help to call the correct gcrypt initialization functions (for threading) when starting libvirtd. In libvirt-0.6.4, gcrypt functions do not appear at all.
*Quickly* porting to OpenSSL as a workaround is not an option, I guess ;-)
I will now try to use a singleton connection object as a workaround but please could somebody solve this problem?
Created attachment 354198 [details]
Initialize threading callbacks with libgcrypt
This patch is a proof of concept fix for the gcrypt threading initialization.
I've not tested this beyond just making sure it compiles. Instead of using gcrypt's default pthread impl I've used libvirt's thread API. This maps to pthreads on all platforms, except Win32 when it maps to native Win32 threads
Included in 0.7.6 release