My application, written in C++, loads a shared library (dylib) written in Go, and uses cgo to interact with that library. The App sets callbacks that are later called from within goroutines managed by the library. One of these callbacks uses a pthread_rwlock_t to protect some data. This callback can be called from both C++ threads in the main application and Go threads created by the Go runtime to serve goroutines. When pthread_rwlock_t is used by both C++ and Go threads, it becomes broken after some time, remaining forever in a locked state despite no threads holding the lock. Note that the Go code does not use pthread_rwlock_t directly; it only calls the C++ callback.

Minimal Reproducer:

I have created a minimal reproducer to demonstrate the issue.

Steps to Reproduce:

1. Build libgolib.dylib: go build -o libgolib.dylib -buildmode=c-shared
2. Build the reproducer: clang -g -o reproducer main.c
3. Run the reproducer: ./reproducer

Expected Result:

The reproducer should constantly print messages to stdout from both C++ and Go code.

Actual Result:

The reproducer hangs after a short time and does not print any messages to stdout. Using lldb to attach to the reproducer process reveals that no thread is holding the rwlock.

Additional Test:

1. Build the reproducer with the TEST_USE_MUTEX option: clang -DTEST_USE_MUTEX -o reproducer main.c. This will use pthread_mutex_t instead of pthread_rwlock_t to protect data.
2. Run the reproducer.
3. Verify that the reproducer constantly prints messages to stdout from both C++ and Go code.

Platform-Specific Issue:

I have tested the reproducer on Ubuntu, and it works as expected without any hangs. The issue appears to be specific to the macOS platform. Since I'm not sure who is responsible for the problem, I have decided to submit a bug report to both Google and Apple.

go_playground.zip
reproducer_46118.spindump.txt