Gratuitous gcry_fast_random_poll (Was: Re: [GNUnet-developers] _gcry_ath_mutex_lock)

[Christian Grothoff]

[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 
completely gratuitous 

  /* If the application missed to call the random poll function, we do
     it here to ensure that it is used once in a while. */
  _gcry_fast_random_poll ();
  

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 
datastructures.

> 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.