X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_83,SPF_PASS,WEIRD_PORT
X-Spam-Check-By: sourceware.org
Message-ID: <4A509DC5.6070506@gmail.com>
Date: Sun, 05 Jul 2009 13:34:13 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: How to spawn from big-stack program
References: <af075b00906260708h674121f3s63fdc79af5675a44 AT mail DOT gmail DOT com>    <416096c60906270139y33e2888cq148430eebb744b71 AT mail DOT gmail DOT com>    <20090628103010 DOT GT30864 AT calimero DOT vinschen DOT de>    <af075b00907020941i666bed61vc450315c662b757a AT mail DOT gmail DOT com>    <20090702174425 DOT GC9839 AT ednor DOT casa DOT cgf DOT cx>   <af075b00907030218p54b606ds813e824422de04fa AT mail DOT gmail DOT com>    <20090703104423 DOT GA18746 AT calimero DOT vinschen DOT de>   <20090703150212 DOT GA26858 AT ednor DOT casa DOT cgf DOT cx>    <20090704161431 DOT GB11034 AT ednor DOT casa DOT cgf DOT cx>   <20090705001152 DOT GA2510 AT ednor DOT casa DOT cgf DOT cx>  <416096c60907050233q344d37cds41859c611c7ab660 AT mail DOT gmail DOT com> <Pine DOT LNX DOT 4 DOT 64 DOT 0907051226240 DOT 2008 AT tyr DOT diku DOT dk>
In-Reply-To: <Pine.LNX.4.64.0907051226240.2008@tyr.diku.dk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Klaus Grue wrote:
> Hi,
> 
> Can anyone tell me how to invoke a program from a big-stack program
> (i.e. a program which has a big stack). Here is a small big-stack
> program which reproduces the problem:

  The problem is not spawning the new executable.  The problem is that you've
set the default thread stack size to 500 meg.  Your main thread starts up,
that's half a gig gone.  The cygwin internal signal handling thread starts up,
another half a gig gone.  You've only got 2 gig of user-addressable memory
space, and there's a lot of DLLs at the top of it and your exe down at the low
end.  When you try and spawn the new process, cygwin needs to fire up another
internal thread to handle synchronisation with the newly-started process.
This takes place at /gnu/winsup/src/winsup/cygwin/pinfo.cc:955:

953       waiter_ready = false;
954       /* Fire up a new thread to track the subprocess */
955       cygthread *h = new cygthread (proc_waiter, 0, this, "proc_waiter");

... where it constructs a new cygthread object; the cygthread constructor at
/gnu/winsup/src/winsup/cygwin/cygthread.cc:189 calls CreateThread:

188     cygthread::cygthread (LPTHREAD_START_ROUTINE start, size_t n, void *param,
189                           const char *name, HANDLE notify)
190      : __name (name), func (start), arglen (n), arg (param),
notify_detached (notify)
191     {
192       thread_printf ("name %s, id %p", name, id);
193       HANDLE htobe;
194       if (h)
195         {
    [ .. snipped ... not relevant here ... ]
203         }
204       else
205         {
206           stack_ptr = NULL;
207           htobe = CreateThread (&sec_none_nih, 0, is_freerange ?
simplestub: stub,
208                                 this, 0, &id);
209           if (!htobe)
210             api_fatal ("CreateThread failed for %s - %p<%p>, %E", name, h,
id);

  But there simply isn't quite enough room (the memory map is a bit fragged by
the layout described above) for another 500 meg stack, so the thread creation
fails and everyone goes home and sulks.

  It's possible we could tweak cygwin to not use the default thread stack size
for these internal threads.

  If you want a workaround, you could try leaving the default thread size in
your executable, and in your main() function use pthread_create to spawn a
worker thread to do the real processing, having set a large stacksize for it
using the related pthread_attr_setstacksize function.

> On the Vista machine I did
>   cygcheck -s -v -r > cygcheck.out
> I stopped it after it had generated 10MB of output. I have merely
> attached the first 39329 bytes of cygcheck.out. It looks like cygcheck
> loops indefinitely.

  Hmm, are you running with a slightly outdated version?  I thought we had
fixed that one.  (MS decided to change the registry from a simple tree to a
directed graph with cycles in order to support WoW64.  Not a clever move IMO).

    cheers,
      DaveK


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