Re: RE: Regression in Cygwin 3.6.9: Deadlock when spawning many concurrent Windows-native processes (nmake.exe) — works in 3.6.5 1

[Mark Geisert]

Hello Nick,

On 9/10/2026 10:18 AM, Nick Popoff via Cygwin wrote:
> Hello,
> 
> Just upgraded to Cygwin 3.6.10-1:
> 
> C:/cygwin64/home/Nick> uname -a
> CYGWIN_NT-10.0-26100 LIBRA 3.6.10-1.x86_64 2026-07-13 20:20 UTC x86_64 Cygwin
> 
> and the problem is still NOT resolved.  See the attached Process Explorer screenshot, where you can see this time 5 hanging nmake processes.  The machine is idling.   I now need to kill everything, restore Cygwin 3.6.5-1, and start over.  This is a severe problem that was introduced recently and not yet resolved.
> 
> Nick
> 
> 
>> -----Original Message-----
>> From: Takashi Yano <takashi.yano@nifty.ne.jp>
>> Sent: Monday, August 24, 2026 6:41 AM
>> To: cygwin@cygwin.com
>> Cc: Nick Popoff <nick@nickpopoff.net>
>> Subject: Re: Regression in Cygwin 3.6.9: Deadlock when spawning many
>> concurrent Windows-native processes (nmake.exe) — works in 3.6.5 1
>>
>> Thanks for the report.
>>
>> I guess the patch:
>> https://cygwin.com/pipermail/cygwin-patches/2026q3/015286.html
>> fixes the issue. Please wait for test version of cygwin, where the patch
>> applied. The patch is now under review, so hopefully it will become soon.

I am unsure at the moment whether the most recent version of this patch 
has made it into released Cygwin.  That's why a test version was 
suggested (by Takashi).

>>
>> On Mon, 24 Aug 2026 06:22:06 -0400
>> Nick Popoff via Cygwin <cygwin@cygwin.com> wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> Regression in Cygwin 3.6.9: Deadlock when spawning many concurrent
>>> Windows-native processes (nmake.exe) — works in 3.6.5‑1
>>>
>>> Version affected: Cygwin 3.6.9 (latest as of August 2026)
>>>
>>> Version NOT affected: Cygwin 3.6.5‑1 (stable, no issues)
>>>
>>>
>>>
>>> Summary
>>>
>>> Cygwin 3.6.9 introduces a regression in process management that causes
>> complete build deadlock when spawning many concurrent Windows-native
>> processes (specifically nmake.exe). The same workload has run flawlessly for
>> 20+ years on all previous Cygwin versions, including 3.6.5‑1. Under 3.6.9, the
>> build freezes once some parallel job limit is reached, leaving dozens of idle
>> sh.exe processes and stalled nmake.exe processes. Ctrl‑C kills the Windows
>> nmake.exe processes but Cygwin’s sh.exe instances remain stuck, and the
>> terminal never returns control.  Reverting to 3.6.5‑1 immediately restores
>> correct behavior.  This is a reproducible regression in Cygwin’s
>> process/signal/pipe handling.
>>>
>>>
>>>
>>> Environment
>>>
>>> *	Windows Server 2025 (WS2025)
>>> *	Heavy parallel build workload
>>> *	15 concurrent nmake.exe processes
>>> *	Each nmake.exe spawns many short-lived Windows-native tools
>>> *	Cygwin shell (sh.exe) orchestrates the build
>>> *	No Cygwin-native processes involved — all Windows-native
Thanks for the screenshot.  It appears that nmake is calling sh.exe, 
contrary to your description above.  One of the process chains has nmake 
calling cmd.exe which calls diff.exe.  It is unclear whether this is 
Windows diff.exe or Cygwin diff.exe.

Can you please supply the output of 'cygcheck -svr' *as an attachment* 
and also show us the contents of the makefile nmake is operating on?
Feel free to redact any sensitive info (by obscuring it, not deleting it).

The patch mentioned above has gone through numerous iterations because 
the under-the-hood machinations of Cygwin vs Windows processes calling 
each other are pretty hairy.  3.6.5-1 had a simpler, less functional 
interface but the improved interface is being problematic to finish.

Specific, complete examples of failures help us better.

..mark