Bug 512350 - Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Summary: Application using libvirt crashes when having concurrent TLS connections (gnu...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: i386
OS: Linux
low
urgent
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-17 13:34 UTC by Andreas Sommer
Modified: 2010-03-16 17:22 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
: 512367 (view as bug list)
Environment:
Last Closed: 2010-02-11 15:04:11 UTC
Embargoed:


Attachments (Terms of Use)
Initialize threading callbacks with libgcrypt (1.86 KB, patch)
2009-07-17 19:22 UTC, Daniel Berrangé
no flags Details | Diff

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


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