https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126380
Bug ID: 126380
Summary: RTEMS: A condition variable wait can be called with an
unlocked mutex
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chrisj at rtems dot org
Target Milestone: ---
A C++ application on RTEMS silently allowed a call to a C++ condition variable
to wait when the mutex was unlocked, ie the mutex was not held by the calling
thread when the CV wait call was made. Building the application against RTEMS
with `RTEMS_DEBUG = true` results in an fatal error as RTEMS's SCORE mutex
unlock code has an assert check. We think an exception should be raised.
We have a GitLab issue in our project to track the problem. The link is
https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5641. This issue here is
to track any changes in GCC and any GCC related discussions.
Our wrapping of the mutex lock and unlock needs to be better and we will work
on this. We should move our GCC support to use our self contain API however
that API is lacking a suitable error check as well. GCC should not be making
direct calls into the RTEMS SCORE.
Our GitLab issue has some testing we did on Linux and FreeBSD and we are not
sure what this means in relation to the C++ standard. A review of C++11 draft
standard indicates an error returned from `__gthread_mutex_lock()` should raise
an exception. Will libstdc++ raise an exception if this call returns an error?
I looked at the code and I do not think it does but I am not sure.
