delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2006/01/18/11:57:19

X-Spam-Check-By: sourceware.org
Date: Wed, 18 Jan 2006 11:57:03 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Intermittent cygwin heap allocation problem
Message-ID: <20060118165703.GE15870@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20060118163128 DOT GC15870 AT trixie DOT casa DOT cgf DOT cx> <SERRANOY6hlHK91rGGX000001bb AT SERRANO DOT CAM DOT ARTIMI DOT COM>
Mime-Version: 1.0
In-Reply-To: <SERRANOY6hlHK91rGGX000001bb@SERRANO.CAM.ARTIMI.COM>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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 Wed, Jan 18, 2006 at 04:41:08PM -0000, Dave Korn wrote:
>Christopher Faylor wrote:
>> On Wed, Jan 18, 2006 at 04:18:09PM +0000, Cliff Hones wrote:
>>> Can this explain failures to initialize executables which don't use
>>> threads? I don't know, but I wouldn't have thought 'ls' uses threads.
>> 
>> Every cygwin application (and probably every windows application) uses
>> threads.  The above scenario only happens when there is a system thread
>> starting before cygwin is initialized but there are sometimes mysterious
>> threads being started during process initialization.
>
>I wonder if they sometimes get started from DllEntry of hook dlls?

Yes, that's likely.

>That could account for some of the AV/PFW problems we see reported.

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.

cgf

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


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