This is the mail archive of the
mailing list for the Cygwin project.
Re: Intermittent cygwin heap allocation problem
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).
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html