pythongh-126688: Reinit import lock after fork

The PyMutex implementation supports unlocking after fork because we
clear the list of watiers in parking_lot.c. This doesn't work as well
for _PyRecursiveMutex because on some systems, such as SerenityOS, the
thread id is not preserved across fork().

Include/internal/pycore_lock.h

@@ -162,6 +162,12 @@ PyAPI_FUNC(int) _PyRecursiveMutex_IsLockedByCurrentThread(_PyRecursiveMutex *m);
 PyAPI_FUNC(void) _PyRecursiveMutex_Lock(_PyRecursiveMutex *m);
 PyAPI_FUNC(void) _PyRecursiveMutex_Unlock(_PyRecursiveMutex *m);
 
+static inline void
+_PyRecursiveMutex_at_fork_reinit(_PyRecursiveMutex *m)
+{
+    memset(m, 0, sizeof(*m));
+}
+
 
 // A readers-writer (RW) lock. The lock supports multiple concurrent readers or
 // a single writer. The lock is write-preferring: if a writer is waiting while

Misc/NEWS.d/next/Core_and_Builtins/2024-11-11-17-02-48.gh-issue-126688.QiOXUi.rst

@@ -0,0 +1,2 @@
+Fix a crash when calling :func:`os.fork` on some operating systems,
+including SerenityOS.

Modules/posixmodule.c

@@ -678,7 +678,8 @@ PyOS_AfterFork_Child(void)
     _PyEval_StartTheWorldAll(&_PyRuntime);
     _PyThreadState_DeleteList(list);
 
-    _PyImport_ReleaseLock(tstate->interp);
+    // gh-126688: Reinit lock because thread id may differ in child process.
+    _PyRecursiveMutex_at_fork_reinit(&tstate->interp->imports.lock);
 
     _PySignal_AfterFork();