delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2011/02/17/05:27:31

X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 17 Feb 2011 11:27:03 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Fork issues with long command lines and long $PATH
Message-ID: <20110217102703.GA30224@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4D5BB1F1 DOT 1060603 AT smarterphone DOT com>
MIME-Version: 1.0
In-Reply-To: <4D5BB1F1.1060603@smarterphone.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list 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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019