Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Aug 2014 01:58:52 +0200
From: Jens Gustedt <>
Subject: bug in pthread_cond_broadcast


I was thinking about our recent discussion on the availability of a
pthread_cont_t variable right after the broadcast (under certain
circumstances). As byproduct I came up with a test as you may find
attached to this post.

The idea is that there is one main thread and 10 client threads that
send signals and broadcasts back and forth through 10 phases. There is
a sequence of events (mutex locks and unlocks) that is observable from
all threads and thus all threads can deduce when a pthread_cond_t
(called cond_main) has unblocked all waiters of phase i. The client
threads then start a next phase use it with a different mutex than

According to our recent discussion this should all be legal in POSIX.
Now for me, this test crashes/deadlocks with musl pthread.
It runs fine with glibc pthread, and with my latest version of C
threads based on musl (also attached).

I think, the problem for musl pthread is that while some clients start
to mess around with the new cond/mutex combination others trapped
inside a previous wait on the condition. The bookkeeping for the
pthread_cond variable is then mixed up and the program fails.


:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

View attachment "pthread_cond_smasher.c" of type "text/x-csrc" (5387 bytes)

View attachment "thrd11-v5.6.patch" of type "text/x-patch" (49810 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.