This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intermittent cygwin heap allocation problem

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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]