Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: gcrypt

ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed



GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded

karthik3186 at gmail

Feb 4, 2009, 11:52 AM

Post #1 of 1 (1936 views)
ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed

Hi Folks,

This is my first mail to the group. I get the above mentioned
assert in the currently stable libgcrypt 1.4.4. I have seen in many
forums including gcrypt-devel where these asserts were mentioned. But
all the approaches that were recommended aren't being helpful. Below
is the way I am initializing gcrypt engine.


void init_gcrypt()
/* Initialize the libgcrypt engine. Disable the Secured Memory. */
if (!gcrypt_already_initialized)
gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread);
gcry_control(GCRYCTL_DISABLE_SECMEM, 0);
gcrypt_already_initialized = TRUE;

Firstly, Is this the right way to initialize the gcrypt engine?
Secondly, may be a dumb one, is it possible to disable threads in libgcrypt?

If it can help solving the problem, I am using AES256 algorithm for
symmetric encryption. Could moving to some other algorithm, help
resolving this issue ?

Any proven way to avoid these asserts?

Looking for any kind of slightest help.


P.S -- Off topic, is there an overhead to in place encryption than the
one in which an explicit output buffer is provided? If so, where can
find some information on how much the overhead could be? I don't seem
to find this in the libgcrypt reference manual!

Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg

GnuPG gcrypt RSS feed   Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.