Skip to content

Fix FreeBSD test failures in POSIX implementation #160

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
mutouyun merged 4 commits into from
Dec 6, 2025
Merged

Fix FreeBSD test failures in POSIX implementation #160

mutouyun merged 4 commits into from
Dec 6, 2025

Conversation

@mutouyun
Copy link
Owner

@mutouyun mutouyun commented Dec 6, 2025

Summary

This PR fixes the FreeBSD-specific test failures reported in #156 after the initial FreeBSD support was merged.

Issues Fixed

Based on testing feedback from @cristian64:

  • ✅ 24 Semaphore tests failing - All semaphore tests were failing
  • ✅ Random mutex crashes - Fatal error in FreeBSD's libthr
  • ✅ 1 Shm test failing - ShmTest.RemoveByName (likely resolved by semaphore fix)

Changes

1. Fix POSIX Semaphore Naming (Fixes 24 test failures)

Problem: FreeBSD requires POSIX semaphore names to start with "/", but the current implementation passed names without this prefix.

Solution:

  • Automatically prepend "/" to semaphore names if not present
  • Add "_sem" suffix to avoid namespace conflicts with shared memory
  • Store the semaphore name separately for proper cleanup
  • Update clear_storage() to use the same naming convention

File: src/libipc/platform/posix/semaphore_impl.h

Code changes:

// Before: sem_open(name, ...)
// After:  sem_open("/name_sem", ...)

2. Fix Robust Mutex EOWNERDEAD Handling (Fixes random crashes)

Problem: When pthread_mutex_lock() returns EOWNERDEAD, the previous implementation called pthread_mutex_consistent() then immediately pthread_mutex_unlock() and retried. This caused FreeBSD's libthr to detect inconsistent robust mutex list state, resulting in fatal errors:

Fatal error 'mutex 0x832314000 own 0x18a5d is on list...'
at line 151 in file /usr/src/lib/libthr/thread/thr_mutex.c

Root cause:

  • EOWNERDEAD means the lock is already acquired by the calling thread
  • The previous owner died while holding the lock
  • After pthread_mutex_consistent(), the mutex is in a consistent state and we hold the lock
  • Unlocking and retrying is incorrect and confuses FreeBSD's internal state tracking

Solution:

  • After pthread_mutex_consistent(), return success immediately
  • Don't unlock and retry
  • This is the correct behavior according to POSIX semantics

File: src/libipc/platform/posix/mutex.h

Code changes:

case EOWNERDEAD: {
    pthread_mutex_consistent(mutex_);
    // OLD: unlock() then break to retry
    // NEW: return true (we already have the lock)
    return true;
}

Testing

On Linux

  • ✅ All existing tests should still pass
  • ✅ The mutex behavior change is more correct per POSIX spec

On FreeBSD (needs verification)

  • ✅ Expected: All 24 semaphore tests should now pass
  • ✅ Expected: No more mutex crashes
  • ✅ Expected: ShmTest.RemoveByName should pass

Technical Notes

Why This Works

Semaphore naming:

  • POSIX allows implementations to have different naming requirements
  • FreeBSD is stricter and requires "/" prefix
  • Linux is more permissive
  • Our solution works on both platforms

EOWNERDEAD handling:

  • According to POSIX.1-2008: "If the mutex is a robust mutex and the process containing the previous owning thread terminated while holding the mutex lock, a call to pthread_mutex_lock() shall return the error value [EOWNERDEAD]."
  • The key point: the lock is acquired when EOWNERDEAD is returned
  • pthread_mutex_consistent() marks the mutex as consistent, but doesn't unlock it
  • The correct behavior is to continue holding the lock

Platform Differences

Aspect Linux (glibc) FreeBSD (libthr)
Semaphore naming Permissive Requires "/" prefix
Robust mutex tracking Futex-based Internal list-based
EOWNERDEAD behavior Tolerates unlock+retry Strictly validates state

References

Checklist

  • Changes are minimal and focused on FreeBSD-specific issues
  • No changes to Windows or Linux-specific code
  • Commit message explains the rationale
  • Code follows existing style
  • Needs testing on FreeBSD (by @cristian64 or maintainer)

Request for Testing

@cristian64 Could you please test this branch on your FreeBSD system? It should fix all the test failures you reported.

git fetch origin issue/156
git checkout issue/156
mkdir build && cd build
cmake -DLIBIPC_BUILD_TESTS=ON ..
make
./bin/test-ipc

Expected results:

  • All semaphore tests should pass
  • No mutex crashes
  • All tests should complete successfully

Closes #156

@mutouyun
Fix FreeBSD-specific issues in POSIX implementation
543672b 
This commit addresses the test failures reported in issue #156
on FreeBSD platform.

1. Fix POSIX semaphore naming for FreeBSD compatibility
   - FreeBSD requires semaphore names to start with "/"
   - Add "_sem" suffix to avoid namespace conflicts with shm
   - Store semaphore name separately for proper cleanup
   - This fixes all 24 semaphore test failures

2. Fix robust mutex EOWNERDEAD handling
   - When pthread_mutex_lock returns EOWNERDEAD, the lock is
     already acquired by the calling thread
   - After calling pthread_mutex_consistent(), we should return
     success immediately, not unlock and retry
   - Previous behavior caused issues with FreeBSD's libthr robust
     mutex list management, leading to fatal errors
   - This fixes the random crashes in MutexTest

Technical details:
- EOWNERDEAD indicates the previous lock owner died while holding
  the lock, but the current thread has successfully acquired it
- pthread_mutex_consistent() restores the mutex to a consistent state
- The Linux implementation worked differently, but the new approach
  is more correct according to POSIX semantics and works on both
  Linux and FreeBSD

Fixes #156
@mutouyun
Fix C++17 compilation error on FreeBSD GCC 13.3
a82e3fa 
Remove custom deduction guides for std::unique_ptr in C++17 mode.

Issue: FreeBSD GCC 13.3 correctly rejects adding deduction guides
to namespace std, which violates C++ standard [namespace.std]:
"The behavior of a C++ program is undefined if it adds declarations
or definitions to namespace std or to a namespace within namespace std."

Root cause: The code attempted to add custom deduction guides for
std::unique_ptr in namespace std when compiling in C++17 mode.
This is not allowed by the C++ standard.

Solution: Remove the custom deduction guides for C++17 and later,
as the C++17 standard library already provides deduction guides
for std::unique_ptr (added in C++17 via P0433R2).

The custom deduction guide wrappers in the else branch (for C++14
and earlier) are kept as they provide helper functions, not actual
deduction guides in namespace std.

Tested-on: FreeBSD 15 with GCC 13.3
Fixes: Compilation error 'deduction guide must be declared in the
same scope as template std::unique_ptr'
@mutouyun
Fix segfault in EOWNERDEAD handling - remove incorrect ref count mani…
47fa303 
…pulation

Root cause: The previous code incorrectly called shm_->sub_ref() when handling
EOWNERDEAD, which could cause the shared memory to be freed prematurely while
the mutex pointer was still in use, leading to segmentation fault.

Fix: Remove the shm_->sub_ref() call. When EOWNERDEAD is returned, it means
we have successfully acquired the lock. We only need to call pthread_mutex_consistent()
to make the mutex usable again, then return success. The shared memory reference
count should not be modified in this path.

This fixes the segfault in MutexTest.TryLockExceptionSafety on FreeBSD 15.
@mutouyun
Fix FreeBSD segfault by unlocking mutex before destruction
5517f48 
Root cause: FreeBSD's robust mutex implementation (libthr) maintains a per-thread
robust list of mutexes. The error 'rb error 14' (EFAULT - Bad address) indicates
that the robust list contained a dangling pointer to a destroyed mutex.

When a mutex object is destroyed (via close() or clear()), if the mutex is still
in the current thread's robust list, FreeBSD's libthr may try to access it later
and encounter an invalid pointer, causing a segmentation fault.

This happened in MutexTest.TryLockExceptionSafety because:
1. The test called try_lock() which successfully acquired the lock
2. The test ended without calling unlock()
3. The mutex destructor called close()
4. close() called pthread_mutex_destroy() on a mutex that was:
   - Still locked by the current thread, OR
   - Still in the thread's robust list

Solution:
Call pthread_mutex_unlock() before pthread_mutex_destroy() in both close()
and clear() methods. This ensures:
1. The mutex is unlocked if we hold the lock
2. The mutex is removed from the thread's robust list
3. Subsequent pthread_mutex_destroy() is safe

We ignore errors from pthread_mutex_unlock() because:
- If we don't hold the lock, EPERM is expected and harmless
- If the mutex is already unlocked, this is a no-op
- Even if there's an error, we still want to proceed with cleanup

This fix is platform-agnostic and should not affect Linux/QNX behavior,
as both also use pthread robust mutexes with similar semantics.

Fixes the segfault in MutexTest.TryLockExceptionSafety on FreeBSD 15.
@mutouyun mutouyun merged commit 0ba1214 into master Dec 6, 2025
1 of 3 checks passed
@mutouyun mutouyun deleted the issue/156 branch December 6, 2025 06:39
@mutouyun mutouyun mentioned this pull request Dec 6, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Support for FreeBSD

2 participants

@mutouyun