Bug 502871 - Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread" optional
Summary: Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is ...
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: helgrind (other bugs)
Version First Reported In: 3.25 GIT
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: Paul Floyd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-04-16 05:54 UTC by Paul Floyd
Modified: 2025-04-18 17:26 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Floyd 2025-04-16 05:54:43 UTC
On Illumos and Solaris I want to make this optional and off by default.

The Illumos man page for pthread_cond_broadcast says

       The pthread_cond_signal() or pthread_cond_broadcast() functions may be
       called by a thread whether or not it currently owns the mutex that
       threads calling pthread_cond_wait() or pthread_cond_timedwait() have
       associated with the condition variable during their waits; however, if
       predictable scheduling behavior is required, then that mutex is locked
       by the thread calling pthread_cond_signal() or
       pthread_cond_broadcast().

Here is the Illumos implementation of pthread_barrier_wait:

int
pthread_barrier_wait(pthread_barrier_t *barrier)
{
        mutex_t *mp = (mutex_t *)&barrier->__pthread_barrier_lock;
        cond_t *cvp = (cond_t *)&barrier->__pthread_barrier_cond;
        uint64_t cycle;
        int cancel_state;

        (void) mutex_lock(mp);

        if (--barrier->__pthread_barrier_current == 0) {
                barrier->__pthread_barrier_cycle++;
                barrier->__pthread_barrier_current =
                    barrier->__pthread_barrier_count;
                (void) mutex_unlock(mp);
                (void) cond_broadcast(cvp);
                return (PTHREAD_BARRIER_SERIAL_THREAD);
        }

        (void) pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cancel_state);
        cycle = barrier->__pthread_barrier_cycle;
        do {
                (void) cond_wait(cvp, mp);
        } while (cycle == barrier->__pthread_barrier_cycle);
        (void) pthread_setcancelstate(cancel_state, NULL);

        (void) mutex_unlock(mp);
        return (0);
}

The key thing there is
                (void) mutex_unlock(mp);
                (void) cond_broadcast(cvp);

That means that there is a "dubious associated lock" error every time that pthread_barrier_wait fires due to the barrier count reaching zero.
Comment 1 Paul Floyd 2025-04-16 13:51:41 UTC
https://bugs.kde.org/show_bug.cgi?id=392331
^^^
probably the reason that I'll generalise this for all platforms.
Comment 2 Paul Floyd 2025-04-18 17:26:06 UTC
commit 954eadb149d5165700fc3ed6d47e435d3c381531 (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Fri Apr 18 13:35:45 2025 +0200

    Bug 502871 - Make Helgrind "pthread_cond_{signal,broadcast}: dubious: associated lock is not held by any thread" optional