_gcry_ath_mutex_lock: Assertion

[David Goulet]

On 04 Aug (21:55:32), Werner Koch wrote:
> 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.

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 have no ideas why libotr does not register its threading system, maybe
that should change...

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

I don't see any in libotr though.

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

That's a good idea and I can work on make it happen. The problem with
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.

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

Thanks!
David

> 
> 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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140804/914cf57c/attachment.sig>