This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Fork issues with long command lines and long $PATH
- From: Per Kristian Gjermshus <perkristian at smarterphone dot com>
- To: cygwin at cygwin dot com
- Cc: Frank Stevenson <frank at smarterphone dot com>
- Date: Wed, 16 Feb 2011 12:16:01 +0100
- Subject: Fork issues with long command lines and long $PATH
We have had recurring problems where some of our machines suddenly fail
to be able to compile our software. We are using a make based build
system and in certain cases we end up with very long command lines to
the linker.
Initially we observed the issue on Windows 7 machines and basically
tried everything including clean re-install, checking the bloda list,
rebaseall and so on and so forth. The problem would suddenly manifest
itself with no apparent reason.
We therefore decided to spend the time needed to get to the bottom of
this and with the reproduction steps below the problem can be reproduced
on Windows XP as well.
The problem can be reproduced like this:
Get the script http://www.smarterphone.com/cygwin/cygwin-repro and the c
file http://www.smarterphone.com/cygwin/tst.c. Then compile the tst.c
with "gcc -o tst tst.c" and put the executable in the same directory as
cygwin-repro.
Then run ./cygwin-repro. If everything is fine it will print "./tst
stack is at 0x28cd24" and then "Childs stack is at 0x28cd24". (Addresses
may vary but should stay the same for each run)
Then try "export PATH=$PATH:$PATH" to make your path longer. Repeat
until forking starts failing.
0 [main] tst 4084 C:\cygwin\home\pergj\tst.exe: *** fatal error - fork:
can't reserve memory for stack 0x29CB80 - 0x2A0000, Win32 error 487
Apparently the combination of having a very long path together with a
very long command line causes the launched process (tst.exe) to get a
different _tlsbase and stack location. This makes the process unable to
fork() again.
In the failing cases child_info_fork::alloc_stack _tlsbase is compared
with stackbottom and alloc_stack_hard_way is called. The first
VirtualAlloc then always fails.
At this time we don't know if the fix should be in alloc_stack_hard_way
or if it should be to make sure that _tlsbase and stackbottom are always
the same.
--
Per Kristian
Attachment:
cygcheck.out
Description: Text document
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple