Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 512350 - Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Application using libvirt crashes when having concurrent TLS connections (gnu...
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
i386 Linux
low Severity urgent
: ---
: ---
Assigned To: Daniel Veillard
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-17 09:34 EDT by Andreas Sommer
Modified: 2010-03-16 13:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512367 (view as bug list)
Environment:
Last Closed: 2010-02-11 10:04:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Initialize threading callbacks with libgcrypt (1.86 KB, patch)
2009-07-17 15:22 EDT, Daniel Berrange
no flags Details | Diff

  None (edit)
Description Andreas Sommer 2009-07-17 09:34:03 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:

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 Berrange 2009-07-17 15:22:48 EDT
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 Berrange 2010-02-11 10:04:11 EST
Included in 0.7.6 release

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

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