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.
On Mon, 24 Aug 2026 06:22:06 -0400 Nick Popoff via Cygwin <[email protected]> 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 > > > > Steps to Reproduce > > 1. Install Cygwin 3.6.9 > 2. Launch a Cygwin shell > 3. Start 15 parallel Windows-native builds, e.g.: > > Code > > for i in {1..15}; do > > (nmake.exe -f Makefile$i &) > > done > > wait > > Each makefile repeatedly spawns short-lived Windows-native tools > (ASN.1-compiler processes). > > 4. Observe behavior once all 15 jobs are active. > > > > Actual Behavior (3.6.9) > > * Build freezes completely once a certain parallel limit is reached > * All nmake.exe processes become idle > * Dozens of idle sh.exe accumulate > * No CPU usage > * No progress > * Ctrl‑C kills nmake.exe but does not kill sh.exe > * Cygwin console never returns > * Terminal must be forcibly closed > * No such behavior in 3.6.5‑1 > > This is consistent with a signal-thread or pipe inheritance deadlock. > > > > Expected Behavior (3.6.5‑1 and earlier) > > * All 15 parallel nmake.exe processes run normally > * No idle sh.exe accumulation > * No deadlock > * Ctrl‑C cleanly terminates all processes > * Console returns immediately > * Build completes successfully > > This behavior has been stable for decades. > > > > Notes > > This workload is a strong stress test for: > > * spawn.cc > * sigproc.cc > * pipe inheritance > * process table updates > * console control handling > * synchronization primitives > > The regression appears only in 3.6.9. > > > > Conclusion > > Cygwin 3.6.9 introduces a reproducible deadlock when orchestrating many > concurrent Windows-native processes via Cygwin’s shell. This is a regression > from 3.6.5‑1. The issue affects real-world build systems and should be > investigated. > > I can provide: > > * process snapshots > * strace logs > * Windows process tree dumps > * minimal reproduction scripts > > upon request. > > > > Nick > > > > > > > > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation: https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple -- Takashi Yano <[email protected]> -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
