On Thu, Apr 16, 2020 at 09:41:23PM +0200, Harald Koch wrote: > Am 16.04.2020 um 17:54 schrieb Tomas Mraz <tmraz@xxxxxxxxxx>: > > > > error queue of openSSL stays empty. The same code works with > >> openSSL with gzip support („./config enable-zlib ...“, for support of > >> compressed SMIME contents in other application). > >> Do you call the OPENSSL_init_ssl from the main thread or from the > >>> TLS > >>> server thread? > >> I call it from the TLS server thread (created by pthread_create): > >> > >> if (!OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS, NULL)) > >> return; > >> I tried to do it only once (instead of every started thread): no > >> difference. > > I do not see how this error could really happen unless > > OPENSSL_cleanup() is called. > > > > Could you try to set a breakpoint on that function and see if it is > > somehow called inadvertently? > gdb is actually unavailable, so I added a big „printf“ at the beginning of crypto/init.c, recompiled (even without zlib support as I’ve seen there’s much functionality in there), function OPENSSL_cleanup: it’s not called. I’m very sure OPENSSL_cleanup is not called. > > > In addition, I load random data via /dev/urandom (also tested only > >> once or every time the server thread starts): > >> RAND_load_file("/dev/urandom", 256); > > That call should not be necessary. > I removed it just in case it may have an influence. No better result. :( > > > I have a workaround and possibly it’s the solution, I would like to have your valuable statement here: you asked where I call OPENSSL_init_ssl: it’s done in the thread for TLS server. When I initialize it earlier in the main thread, the subsequent generated (second) thread works as expected! Is this spooky or expected behaviour? Just to check: what OS is this on? -Ben