Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5819
`pthread_cond_timedwait()` and `pthread_cond_clockwait()` add the timeout before they release the mutex. With an invalid or past time point, the timeout ends the wait at once with `EINVAL` or `ETIMEDOUT`. The enqueue callout then calls `pthread_mutex_unlock()`. Its failure has no effect, because the wait already ended. `_POSIX_Condition_variables_Wait_support()` sees an error other than `EPERM` and calls `pthread_mutex_lock()`. So a caller which did not own the mutex gets `EINVAL` or `ETIMEDOUT` and then owns the mutex. If another thread owns the mutex, the caller blocks until that thread releases it. The same call with a valid future time point returns `EPERM` and leaves the mutex alone. The fix releases the mutex in `_POSIX_Condition_variables_Enqueue_with_timeout_by_clock_id()` before it adds the timeout. A failed unlock then ends the wait with `EPERM`, and the timeout has no effect. An owned mutex behaves as before. A validation test of `pthread_cond_timedwait()` found the defect. This description was created with Claude Code assistance. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5819 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-e5k5xq1vt8s3ytxbxekvnd9o3-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
