Hi, I'm building a project using gloox-0.9.9.5. The library is configured without any special options and uses GNU TLS (libgnutls-dev, 1.6.3-1ubuntu0.1 on ubuntu 7.10). I have two threads in my application. The worker thread sets up the XMPP connection to the server and blocks in the connect() function. When I call the ClientBase::disconnect function from the main thread however, my program often (but not always) crashes like this: testprog: ath.c:184: _gcry_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed. Running in GDB gives this backtrace: Program received signal SIGABRT, Aborted. [Switching to Thread -1231324272 (LWP 29516)] 0xffffe410 in __kernel_vsyscall () (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb7a97875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7a99201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7a90b6e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xb79ef54d in ?? () from /usr/lib/libgcrypt.so.11 #5 0xb7a277a8 in ?? () from /usr/lib/libgcrypt.so.11 #6 0xb7a27787 in ?? () from /usr/lib/libgcrypt.so.11 #7 0x000000b8 in ?? () #8 0xb79fa98e in ?? () from /usr/lib/libgcrypt.so.11 #9 0xb7a36a88 in ?? () from /usr/lib/libgcrypt.so.11 #10 0x00000000 in ?? () So it is probably crashing somewhere in libgrcypt (which is used by GNU TLS right?). If I configure Gloox like this: './configure --without-openssl --without-gnutls' the error goes away. Any ideas? When running the program in helgrind (part of valgrind) I see this fly by: ==29648== Possible data race during write of size 1 at 0x5278134 ==29648== at 0x814E7FA: gloox::GnuTLSBase::cleanup() (tlsgnutlsbase.cpp:98) ==29648== by 0x814DA41: gloox::GnuTLSClient::cleanup() (tlsgnutlsclient.cpp:36) ==29648== by 0x80E0EA6: gloox::ClientBase::disconnect(gloox::ConnectionError) (clientbase.cpp:351) ==29648== by 0x8103E68: gloox::Client::disconnect() (client.cpp:580) <stuff cut out> ==29648== Old state: shared-readonly by threads #1, #2 ==29648== New state: shared-modified by threads #1, #2 ==29648== Reason: this thread, #1, holds no consistent locks ==29648== Location 0x5278134 has never been protected by any lock I get a big feeling that the access to the GNU TLS library is not properly done with regard to thread safety. Am I right? Any ideas? Kind regards, Benjamin van den Hout
-- gloox-dev mailing list to unsubscribe: send a message with subject 'unsubscribe gloox-dev' to minimalist@xxxxxxxxxx