Re: Fork issues with long command lines and long $PATH

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 16 12:16, Per Kristian Gjermshus wrote:
> 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.

Thanks for the report and especially the testcase.

The problem is that the stack is not created by Cygwin in the first
place, and for some reason the Windows loader appears to need some more
space in the low memory area below the process stack, so the process
stack is moved by 64K.  However, for some other reason the Windows
loader doesn't move the stack from it's default location in the forked
child, despite the fact that  $PATH hasn't changed.  The problem now
is, that the memory area behind the stack is already taken, probably
by same data from one of the loaded system DLLs.  So Cygwin's attempt
to match the child stack with the parent stack doesn't work, because
it can't reserve the upper 64K of the stack space of the parent in
the child.  Therefore the fork failed, because it's not possible to
reproduce the parent stack.

Beats me why the Windows loader neglects to move the stack in the forked
child even though $PATH hasn't changed.  Very puzzeling.  I'm not sure
there's a good solution for this problem.  After all, there's no way
to start a process and tell the Windows loader where you want the stack.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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