public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Fork issues with long command lines and long $PATH
Date: Thu, 17 Feb 2011 10:27:00 -0000	[thread overview]
Message-ID: <20110217102703.GA30224@calimero.vinschen.de> (raw)
In-Reply-To: <4D5BB1F1.1060603@smarterphone.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

  reply	other threads:[~2011-02-17 10:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-16 11:17 Per Kristian Gjermshus
2011-02-17 10:27 ` Corinna Vinschen [this message]
2011-03-11 12:46   ` Daniel Colascione
2011-03-11 15:22     ` Corinna Vinschen
2011-03-11 15:25     ` Christopher Faylor
2011-04-01 13:13       ` Daniel Colascione

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110217102703.GA30224@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).