Bug 512350 - Application using libvirt crashes when having concurrent TLS connections (gnutls problem)
Summary: Application using libvirt crashes when having concurrent TLS connections (gnu...
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt   
(Show other bugs)
Version: unspecified
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
Depends On:
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:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512367 (view as bug list)
Last Closed: 2010-02-11 15:04:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 19:22 UTC, Daniel Berrange
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:


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

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 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 Berrange 2010-02-11 15:04:11 UTC
Included in 0.7.6 release


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