Bug 512350

Summary: Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Product: [Community] Virtualization Tools Reporter: Andreas Sommer <AndiDog>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: urgent Docs Contact:
Priority: low    
Version: unspecifiedCC: berrange, crobinso, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512367 (view as bug list) Environment:
Last Closed: 2010-02-11 15:04:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Initialize threading callbacks with libgcrypt none

Description Andreas Sommer 2009-07-17 13:34:03 UTC 
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:

http://groups.google.com/group/google-gadgets-for-linux-user/browse_thread/thread/2c718e4e56be7a49/d16868d743ac18b4?lnk=raot
http://bugzilla.gnome.org/show_bug.cgi?id=172813

Version-Release number of selected component (if applicable):
libvirt-0.6.4 (from Debian lenny stable repo)

How reproducible:
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.
  
Actual results:
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
  Aborted

Expected results:
Simultaneous TLS connections should not crash the application.

Additional info:
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?
Comment 1 Daniel Berrangé 2009-07-17 19:22:48 UTC 
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
Comment 2 Daniel Berrangé 2010-02-11 15:04:11 UTC 
Included in 0.7.6 release

http://libvirt.org/git/?p=libvirt.git;a=commit;h=33a198c1f6a4a1bc7f34d50a31032e03bec10fee