Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

threadWaitQuit returns with the mutex locked, then threadFree destroys it

Open Beginner friendly
  • Is something wrong?
#85 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c, cpp
Domain
cli

Research direction

The bug is in threadWaitQuit in lib/SRC/ARUtil/thread_sub.c (lines 246-255), which returns while still holding flag->mut; the destroy call is in threadFree at line 198. Read both functions to confirm the lock is never released on the return path, then add pthread_mutex_unlock before return 0. Done when the function unlocks before returning and the ThreadSanitizer run no longer reports destroy of a locked mutex at thread_sub.c:198.

Written by the indexing model from the issue text.

Description

bug C/C++ code

Description

threadWaitQuit() in lib/SRC/ARUtil/thread_sub.c (lines 246-255) locks flag->mut, waits on cond2 until endF == 2, and returns without unlocking. Callers then call threadFree() (line 196+), whose first step is pthread_mutex_destroy(&(*flag)->mut) (line 198): destroying a locked mutex is undefined behaviour in POSIX.

int threadWaitQuit( THREAD_HANDLE_T *flag )
{
    pthread_mutex_lock(&(flag->mut));
    flag->startF = 2;
    pthread_cond_signal(&(flag->cond1));
    while (flag->endF != 2) {
        pthread_cond_wait(&(flag->cond2), &(flag->mut));
    }
    return 0;          // mut is still locked here
}

Evidence

A ThreadSanitizer run of the NFT core tests (webarkit/jsartoolkitNFT#683, webarkit_nft_core_test, filters ThreadedKpmDetectorTest.*:CoreLifecycleTest.*:CoreTrackingTest.Threaded*) passed 16/16 but reported 61 destroy of a locked mutex warnings, all at threadFree (thread_sub.c:198), reached through trackingInitQuit (KPM worker shutdown) and ar2DeleteHandle (threaded AR2 workers).

Pre-existing: every ARToolKit5 consumer of threadWaitQuit + threadFree has it; glibc tolerates it in practice, which is why it never showed up.

Fix

Add pthread_mutex_unlock(&(flag->mut)); before return 0; in threadWaitQuit. Then a sanitizer CI job could run without suppressions for this file.

Dominant language
C++
Stars
21
Forks
8
Avg merge
6h 43m
Merged PRs (30d)
18

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from webarkit/WebARKitLib

All issues in webarkit/WebARKitLib

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.