_gcry_ath_mutex_lock: Assertion

[David Goulet]

On 05 Aug (10:57:17), Werner Koch wrote:
> 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$

Oh so sorry, I should have told you that the test suite we are
developing is in an other repository! My mistake! See below.

>   
> >> 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 obsolete, you should look at:

https://bugs.otr.im/projects/libotr/repository/libotr-next/revisions/test-suites/entry/tests/regression/client/client.c#L42

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

Yes absolutely, just that the test suite needs to use 1.6 but we can
make it happen with some autoconf magic :).

With 1.5.3, we are hitting this original issue of this thread very fast!
with two threads which I had to use a mutex to synchronize the calls to
libotr.

https://bugs.otr.im/projects/libotr/repository/libotr-next/revisions/test-suites/entry/tests/regression/client/client.c#L86

This workaround is ok for now. I'll make it work with 1.6 and see if I
can remove that lock.

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

Ah superb! This is very helpful, much appreciate!

Cheers!
David

> 
> 
> Shalom-Salam,
> 
>    Werner
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140805/e5c46f72/attachment.sig>