X-Spam-Check-By: sourceware.org Date: Wed, 18 Jan 2006 11:57:03 -0500 From: Christopher Faylor 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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/