Deadlock of the process tree when running make

Brian Inglis
Fri Apr 8 17:04:03 GMT 2022

On 2022-04-08 02:42, Alexey Izbyshev wrote:
> On 2022-04-08 02:54, Brian Inglis wrote:
>> I've seen infinite loops with readlink in build scripts under Cygwin.
>> Seeing that readlink in a process tree makes me suspicious that
>> something in a shell script is looping because two paths never match
>> or always match under Cygwin.
>> Often there is one constant path and a varying path which is subjected
>> to readlink in a loop.
>> Under Cygwin, you may have to pass the first path through readlink and
>> compare that resulting path against the varying value.
> Thanks, but I don't think I have such loops in this project. Also, other 
> processes hang in independent make jobs, so a hang around readlink 
> wouldn't explain that.
> There is also an additional detail that I forgot to mention: in the 
> stack trace of all leaf processes as displayed by ProcessHacker, it 
> seems that the executable entry point is not reached yet. The only 
> non-Windows-DLL location is in cygwin1.dll, so I suspect that all 
> processes hang at early initialization in Cygwin's DLL entry point.

That sounds like BLODA interference from AntiVirus programs:

and can also happen if you use Windows AD, and your users have a lot of 
rights, and a slow server, firewall filtering, or network link, but 
known issues were fixed a few releases ago.

Any idea how much address space is used by Cygwin DLLs, and memory by 
all the processes running: run rebase -is to see if you could be out of 
address space for Cygwin and DLLs, and how much is left for processes?

Do you have a decent amount of memory free on your system while running, 
and Windows paging space allocated to back it up - total twice memory, 
and do you have multiple drives to spread it across?
Check your system memory and paging activity while those processes are 

Could you try installing Cygwin64 packages and running those instead of 
Cygwin32 (recommended as Cygwin32 support will be dropped next release) 
as there is more address space available as well as usable memory for 

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

More information about the Cygwin mailing list