X-Spam-Check-By:	sourceware.org
Message-ID:	<43CE75E8.1050200@hones.org.uk>
Date:	Wed, 18 Jan 2006 17:07:52 +0000
From:	Cliff Hones <cliff AT hones DOT org DOT uk>
User-Agent:	Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Intermittent cygwin heap allocation problem
References:	<20060118163128 DOT GC15870 AT trixie DOT casa DOT cgf DOT cx> <SERRANOY6hlHK91rGGX000001bb AT SERRANO DOT CAM DOT ARTIMI DOT COM> <20060118165703 DOT GE15870 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To:	<20060118165703.GE15870@trixie.casa.cgf.cx>
X-Spam-Score:	-2.5 (--)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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

Christopher Faylor wrote:
> ... 
> One scenario that I have seen is that a thread gets started when someone
> hits CTRL-C while a forked process is starting up.  Since only one
> thread can execute at a time when a process is in DLL initialization,
> the "other" thread's stack gets allocated but it hangs while cygwin
> vainly tries to complete its initialization.  I say "vainly" because the
> initialization is doomed to fail since the other thread's stack has
> often been allocated in cygwin's heap area.
> 
> Attempts to move the heap elsewhere just result in other collisions.
> 
> I spent some time looking into the NT-specific functions which allow one
> to turn off the serialization of the startup code, to allow cygwin to
> break out of the code during startup and let other threads complete
> their dirty work but the big flashing warning signs and threats of doom
> that accompanied every discussion about these functions sort of scared
> me off.
> 
> 1.5.19 may have aggravated this problem since Corinna's changes to mmap
> now use VirtualAlloc'ed space for privately mmapped areas.  For some
> inexplicable reason, this causes more of this type of collision.  I
> would swear that once a program uses a memory area in a parent, windows
> is much more likely to use that memory for system-like things in the
> "forked/execed" child.

Since it seems that there's no solution to this, once Windows has
pinched some of the heap area (for whatever reason), could my partly
facetious suggestion for the parent to have another go actually be
a useful way to go?  The borked child would have to be able to
exit cleanly without generating an error message, and the parent
would need to detect this case (which I guess could be a problem).

-- Cliff

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -