Helgrind: a thread error detector
• destroying an invalid or a locked mutex
• recursively locking a non-recursive mutex
• deallocation of memory that contains a locked mutex
• passing mutex arguments to functions expecting reader-writer lock arguments, and vice versa
• when a POSIX pthread function fails with an error code that must be handled
• when a thread exits whilst still holding locked locks
• calling
pthread_cond_wait
with a not-locked mutex, an invalid mutex, or one locked by a different thread
• inconsistent bindings between condition variables and their associated mutexes
• invalid or duplicate initialisation of a pthread barrier
• initialisation of a pthread barrier on which threads are still waiting
• destruction of a pthread barrier object which was never initialised, or on which threads are still waiting
• waiting on an uninitialised pthread barrier
• for all of the pthreads functions that Helgrind intercepts, an error is reported, along with a stack trace, if the system
threading library routine returns an error code, even if Helgrind itself detected no error
Checks pertaining to the validity of mutexes are generally also performed for reader-writer locks.
Various kinds of this-can’t-possibly-happen events are also reported.
These usually indicate bugs in the system
threading library.
Reported errors always contain a primary stack trace indicating where the error was detected. They may also contain
auxiliary stack traces giving additional information. In particular, most errors relating to mutexes will also tell you
where that mutex first came to Helgrind’s attention (the "
was first observed at
" part), so you have a chance
of figuring out which mutex it is referring to. For example:
Thread #1 unlocked a not-locked lock at 0x7FEFFFA90
at 0x4C2408D: pthread_mutex_unlock (hg_intercepts.c:492)
by 0x40073A: nearly_main (tc09_bad_unlock.c:27)
by 0x40079B: main (tc09_bad_unlock.c:50)
Lock at 0x7FEFFFA90 was first observed
at 0x4C25D01: pthread_mutex_init (hg_intercepts.c:326)
by 0x40071F: nearly_main (tc09_bad_unlock.c:23)
by 0x40079B: main (tc09_bad_unlock.c:50)
Helgrind has a way of summarising thread identities, as you see here with the text "
Thread #1
". This is so that it
can speak about threads and sets of threads without overwhelming you with details. See
below
for more information
on interpreting error messages.
7.3. Detected errors: Inconsistent Lock
Orderings
107