On Mon, Dec 16, 2013 at 21:19:31 -0500, Ian Goldberg wrote: > On Tue, Dec 17, 2013 at 01:36:52AM +0100, Martin Milata wrote: > > Hi! > > > > I'm writing a program that uses libotr-4.0.0 and encountered a problem > > when trying to perform key generation in backtround thread. > > > > When the key generation is running and another OTR query is received by > > libotr the program crashes with following stacktrace: > > > > ath.c:193: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' > > failed. > > What's supposed to happen is when you try to generate the key for the > same account the second time, otrl_privkey_generate_start will return > gcry_error(GPG_ERR_EEXIST), and *newkeyp is set to NULL. Are you > checking for this? The second OTR query should not cause a launch of a > background thread at all. > > Or do you mean you received OTR Query messages for two _different_ local > accounts? > > But more generally, libotr has no way of knowing what threading library > your application is using, so your application may well need to call the > gcry_control to enable multithreading. Does the problem go away if you > do that before calling OTRL_INIT?
This happens despite checking the otrl_privkey_generate_start return value. I think it would happen for two different local accounts as well. In any case, calling gcry_control beforehand worked, howerver there still exists similar problem. Again, when key is being generated in the background and another OTR query arrives and the system is very low on entropy (typical for virtual servers), the main thread blocks until the private key is generated: Keygen thread: #0 poll #1 _gcry_rndlinux_gather_random #2 read_random_source #3 _gcry_rngcsprng_randomize #4 _gcry_random_bytes_secure #5 dsa_generate_ext #6 _gcry_pk_genkey #7 otrl_privkey_generate_calculate #8 COtrMod::GenKeyThreadFunc #9 start_thread #10 clone Main thread: #0 __lll_lock_wait #1 _L_lock_790 #2 pthread_mutex_lock #3 lock_pool #4 initialize #5 _gcry_rngcsprng_randomize #6 _gcry_random_bytes_secure #7 otrl_dh_gen_keypair #8 otrl_auth_start_v23 #9 otrl_message_receiving #10 COtrMod::OnPrivMsg ...continues There doesn't appear to be a simple solution for this except advising the users to install an entropy-gathering daemon such as haveged on the VM. Cheers, Martin _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
