Gratuitous gcry_fast_random_poll (Was: Re: [GNUnet-developers]
christian at grothoff.org
Tue May 4 06:52:52 CEST 2004
[Also to gcrypt-devel since I believe this is partially libgcrypt's fault]
I figured it out. While the way that we're using libgcrypt should not require
any synchronization for this code, the code does in gcry_cipher_open the
/* If the application missed to call the random poll function, we do
it here to ensure that it is used once in a while. */
Now, while creating a symcipher and doing some encryption with it should not
require locking, the random_poll operation does require locking. Now, GNUnet
does not do any locking here (since we assumed that no locking would be
required) -- which results in the assertion failure you describe below (given
concurrent use). Now, we can fix it by doing more (useless) locking in
GNUnet (will patch), but I'll CC this to libgcrypt-devel since I believe they
should avoid doing such calls that require locks on paths that one would
commonly not consider accessing the random-pool or other global
> On Monday 03 May 2004 08:05, Glenn McGrath wrote:
> > Ive uploaded debian packages of 0.6.2, however ive just realised i have
> > a problem with it, i get the following error.
> > gnunetd: ath.c:181: _gcry_ath_mutex_lock: Assertion `*lock ==
> > ((ath_mutex_t) 0)' failed.
> > I built the deb against libgcrypt-1.2.0, to doso i copied the files
> > src/util/hostkey_gcrypt.c and src/util/symcipher_gcrypt.c from cvs.
> > The gcrypt function in question is ath_mutex_lock(), it tried tracking
> > it down using gdb but had no luck.
More information about the Gcrypt-devel