another thread may simultaneously be doing a cmalloc/cfree while the cygheap is being copied to the child.
Addresses: https://cygwin.com/pipermail/cygwin/2025-September/258801.html Signed-off-by: Jeremy Drake <cyg...@jdrake.com> --- I'm seeing a timeout failure of pthread/cancel2.exe test in GitHub CI. This seems to be happening even without this change, so perhaps it is more to do with the update to windows-2025 runners? In any event, this prevents the 'stress' jobs from running against this change. winsup/cygwin/fork.cc | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc index 4abc525986..7156fc31de 100644 --- a/winsup/cygwin/fork.cc +++ b/winsup/cygwin/fork.cc @@ -329,6 +329,7 @@ frok::parent (volatile char * volatile stack_here) /* NEVER, EVER, call a function which in turn calls malloc&friends while this malloc lock is active! */ __malloc_lock (); + cygheap->lock (); bool locked = true; /* Remove impersonation */ @@ -483,6 +484,7 @@ frok::parent (volatile char * volatile stack_here) impure, impure_beg, impure_end, NULL); + cygheap->unlock (); __malloc_unlock (); locked = false; if (!rc) @@ -568,7 +570,10 @@ cleanup: if (fix_impersonation) cygheap->user.reimpersonate (); if (locked) - __malloc_unlock (); + { + cygheap->unlock (); + __malloc_unlock (); + } /* Remember to de-allocate the fd table. */ if (hchild) -- 2.51.0.windows.1
