Re: [Mingw-msys] Couldn't reserve space for cygwin's heap win32 error 6 MSYS Version 1.0.11

[Keith M. <kei...@us...>]

On Sunday 27 June 2010 01:30:30 JonY wrote:
> On 6/27/2010 08:11, Robert Matlock wrote:
> > Hello All,
> >
> > Having this error in postinstall with msys version 1.0.11. Get
> > the following error:
> >
> > Couldn't reserve space for cygwin's heap win32 error 6 MSYS
> > Version 1.0.11
> >
> > Apparently this error goes back as far as 2006.

Unfortunately, it wasn't until 2010 that those in a position to do 
anything about it were made aware of it.  Since it was brought to our 
attention, there has been some considerable discussion on the MinGW 
Developers' list:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3831

> > Is there a fix? 

There is a work around; it requires reassignment of the preferred 
loading (base) address for msys-1.0.dll, as set within the DLL 
itself.

> > I'm running XP sp3. All upgrades current.
>
> Hi,
>
> this is not a bug, ...

Yes, it is.

> it is due of other software interfering with 
> MSYS. Check the BLODA list:
>
> http://cygwin.com/faq/faq.using.html#faq.using.bloda

This may be a contributing factor, but it isn't necessarily so.

> These software inject themselves indiscriminately causing all sorts
> of problems.

Yes, they do, and often in non-deterministic ways, which may not even 
be reliably reproducible, and hence are very difficult to diagnose 
and debug.  However, the problem in this case is congestion in the 
DLL loading address space, where msys-1.0.dll prefers to be loaded; 
there isn't sufficient space, and the Windows loader can't find a 
suitable relocation address.  No matter what address is chosen, there 
is always a possibility of conflict.  The address which was chosen 
just seems to be resulting in such conflicts more frequently now, 
than it used to.  The maintainer will try to use a less contentious 
address for future releases, but whatever address is chosen, some 
potential for conflict must always exist, (and BLODAs will increase 
that potential); sadly, some users may always be faced with a need to 
rebase the DLL.

-- 
Regards,
Keith.