_gcry_ath_mutex_lock: Assertion

[Werner Koch]

On Mon,  4 Aug 2014 22:13, dgoulet at ev0ke.net said:

> Right now, with current state of libotr, it's the application job to do
> that which we *do* in our test client.
>
> 	GCRY_THREAD_OPTION_PTHREAD_IMPL;

I can't see that:

  wk at wheatstone:~/s/libotr$ git branch -v
  * master 3172d79 Use a constant-time memory comparison for safety.
  wk at wheatstone:~/s/libotr$ find . -type f | xargs grep GCRY_THREAD_OPTION
  wk at wheatstone:~/s/libotr$
  
>> I recall that we discussed the threading issue some years ago and it
>> might be that you did some workaround by protecting gcry_ calls with
>> your own mutexes.  That is quite fragile.
>
> I don't see any in libotr though.

I guessed that because I  noticed PTHREAD_MUTEX_INITIALIZER in
test_suite/otr_c_client/dummy_client.c

> this is packages in distribution that supports libotr but does not have
> libgcrypt 1.6 but for system that do supports it, that should be done
> anyway.

Well, due to the ABI change (different SO number) it is not a problem to
install it in addition to 1.5.3.

> Also, libotr has never claimed to be thread safe but if it happens to be
> someday, is libgcrypt >= 1.6 "stamped thread safe" ?

libgcrypt < 1.6 was thread safe as well.  As with many libraries you
were required to install callback.  Since 1.6 we have

/* NOTE: Since Libgcrypt 1.6 the thread callbacks are not anymore
   used.  However we keep it to allow for some source code
   compatibility if used in the standard way.  */

Form the manual:

  As mentioned earlier, the Libgcrypt library is thread-safe if you
  adhere to the following requirements:
  
     * If you use pthread and your applications forks and does not
       directly call exec (even calling stdio functions), all kind of
       problems may occur.  Future versions of Libgcrypt will try to
       cleanup using pthread_atfork but even that may lead to problems.
       This is a common problem with almost all applications using
       pthread and fork.
  
     * The function `gcry_check_version' must be called before any other
       function in the library.  To achieve this in multi-threaded
       programs, you must synchronize the memory with respect to other
       threads that also want to use Libgcrypt.  For this, it is
       sufficient to call `gcry_check_version' before creating the other
       threads using Libgcrypt(1).
  
     * Just like the function `gpg_strerror', the function
       `gcry_strerror' is not thread safe.  You have to use
       `gpg_strerror_r' instead.
  


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.