scePthreadMutexUnlock resolved the slot with resolveMutex(mutex, false),
which throws "Mutex is not initialized" while the slot still holds the
static initializer (0) or the adaptive static initializer (1), so
unlocking a statically initialized mutex that was never locked ended
the process. FreeBSD 11.4's mutex_unlock_common returns EPERM for both
without initializing the slot, and EINVAL for the destroyed marker.
Load the slot once: the destroyed marker still returns 0x80020016, and
the two initializers now return 0x80020001 and stay in the slot, so a
later lock still creates the mutex.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Locking, trylocking, unlocking a destroyed mutex and signalling, broadcasting,
waiting on or destroying a destroyed condition variable threw a C++ exception
into the guest. FreeBSD 11.4 libthr returns EINVAL for all of them (thr_mutex.c
check_and_init_mutex and mutex_unlock_common compare against THR_MUTEX_DESTROYED,
thr_cond.c CHECK_AND_INIT_COND and _pthread_cond_destroy against
THR_COND_DESTROYED). The condition wait path already reported EINVAL for a
destroyed mutex.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
