Mailing List Archive: Thread safety problem (?)

Greetings,

I use gcrypt in a multithreaded server app (namely, nufw [1]) (also uses
glib and gnutls).

We experiment an occasionnal (hard to reproduce) crash which seems to
always occur at the gnutls call : gnutls_handshake(). The crash is quite
rare (and occurs in an often called loop), which leads us to believe
this might be a thread safety problem.

Gnutls people pointed us (on this thread [2]) to the gcrypt, and told us
we should use some locking mechanisms. Also, the "Multi-threaded
applications" [3] webpage seems to be of interest.

Our server runs this :
static struct gcry_thread_cbs gcry_threads_gthread =
{
GCRY_THREAD_OPTION_USER, NULL,
gcry_gthread_mutex_init, gcry_gthread_mutex_destroy,
gcry_gthread_mutex_lock, gcry_gthread_mutex_unlock
};

and this :

g_thread_init(NULL);
gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_gthread);
gnutls_global_init();

which doesn't seem to be enough to solve our problem.

As usual, the thread safety problems are very delicate, and we of course
cannot be sure this is gcrypt's "fault" or ours, or whatever.

If anyone on this list has more ideas about what to check/add, we will
be very interested to hear about it.

Any help/pointer will be appreciated.

Thanks for reading me,

Vincent Deffontaines

[1] http://www.nufw.org/
[2] http://lists.gnu.org/archive/html/help-gnutls/2005-04/msg00009.html
[3]
http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications

On Mon, Apr 18, 2005 at 05:51:03PM +0200, Vincent Deffontaines wrote:

Hello Vincent,

> We experiment an occasionnal (hard to reproduce) crash which seems
> to always occur at the gnutls call : gnutls_handshake(). The crash
> is quite rare (and occurs in an often called loop), which leads us
> to believe this might be a thread safety problem.

Since your initialization in respect to the threading system looks
correct, there are two possibilities:

1) the problem is indeed in Libgcrypt and thus you have found a new
bug;
2) the problem is not in Libgcrypt.

I cannot exclude the one or the other. You could try to do the
following: protect all calls into Libgcrypt by a shared lock; this
way, Libgcrypt would never be used by two threads at the same time.
If the problem keeps being reproducible, 1) should be excludable.

Thanks,
Moritz

--
Moritz Schulte