_gcry_ath_mutex_lock: Assertion

Werner Koch wk at gnupg.org
Mon Aug 4 21:55:32 CEST 2014


Hi,

checking out the repo shows that libotr does not register thread
callbacks and thus it is not supposed to work.  Right, there are
problems with a plugin registering thread callbacks and it would be
correct if the main application does this.  I am pretty sure that does
not happen.

The only init you do is in otrl_sm_init which is correct but not
sufficient.

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.

Given that you need Pthread anyway, you should change the main
application to init the the threading system.  However, a far better
solution is to go with Libgcrypt 1.6 which uses pthreads native on Linux
and the initialization task is thus much easier.  1.6. is also much
faster and more cleaned up.  I would really recommend to do that.  There
is an ABI break and thus there is no problem installing both runtime
versions.  Your modifications should be minimal to none (as you can see
by the fact that it works with 1.6).

Note that libgpg-error 1.13 added a portable Mutex API which will be
used by Libgcrypt 1.7.  You may opt to use it also to make libotr better
portable.  The libgpg-error Mutex API is a little bit slower than a
native one but it is easier to work with as it does not introduce build
dependencies and it is availabale anyway due to the use of Libgcrypt.


Salam-Shalom,

   Werner


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




More information about the Gcrypt-devel mailing list