Occasionally I have a problem with MSYS tools on Windows 7

[Octagon]

Evidently, this is an MSYS problem the Installer should mention
somewhere in the docs.

When I tried to compile an old patched version of eventmachine with
the latest devkit, I got the following error from gcc: "Couldn't
reserve space for cygwin's heap, Win32 error 0". Shortly after that I
tried to compile the unpatched version of eventmachine and it compiled
OK. I also ran msys.bat seveeral times without any problems.

When I tried to run msys.bat again after Windows reboot, I got the
same error message from rxvt.

In both cases, running As Administrator was successful.

So, the problem looks Windows 7 specific and happens occasionally. I
guess nothing can be done to it but a warning placed somewhere.

[Luis Lavena]

On Wed, Dec 2, 2009 at 3:01 PM, Octagon <g...@kaluga.ru> wrote:
> Evidently, this is an MSYS problem the Installer should mention
> somewhere in the docs.
>

The DevKit only promotes the compilation process and exposes the
minimal set of tools to avoid interfering with your system.

> When I tried to compile an old patched version of eventmachine with
> the latest devkit, I got the following error from gcc: "Couldn't
> reserve space for cygwin's heap, Win32 error 0". Shortly after that I
> tried to compile the unpatched version of eventmachine and it compiled
> OK. I also ran msys.bat seveeral times without any problems.
>

Never encountered the issue you mention. Used Windows 7 x64 in both 64
and 32 bits prompt versions and successfully compiled eventmachine
gem.

> When I tried to run msys.bat again after Windows reboot, I got the
> same error message from rxvt.
>

rxvt has issues with Vista and newer versions of Windows. that is one
of the reasons none of these functions are exposed by the DevKit.

There is code in msys.bat that detects Windows Vista, seems is failing
in your case but worked here.

> In both cases, running As Administrator was successful.
>
> So, the problem looks Windows 7 specific and happens occasionally. I
> guess nothing can be done to it but a warning placed somewhere.
>

This seems to be pretty specific to your situation, as I'm running
under a high constrained (UAC enabled) Windows 7 environment and never
encountered the issues you mention.

Please include environment information, PATH, ruby version installed
and complete output of the issue for us trying to replicate and
consider a bug.

Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[rogerdpack]

> When I tried to compile an old patched version of eventmachine with
> the latest devkit, I got the following error from gcc: "Couldn't
> reserve space for cygwin's heap, Win32 error 0". Shortly after that I
> tried to compile the unpatched version of eventmachine and it compiled
> OK. I also ran msys.bat seveeral times without any problems.

Do you have cygwin installed? (wondering if it's calling out to a
cygwin binary on accident).
-r

[Alexey Borzenkov]

I think it's called cygwin's heap because msys was based on cygwin...

[Octagon]

> > So, the problem looks Windows 7 specific and happens occasionally. I
> > guess nothing can be done to it but a warning placed somewhere.
>
> This seems to be pretty specific to your situation, as I'm running
> under a high constrained (UAC enabled) Windows 7 environment and never
> encountered the issues you mention.
>
> Please include environment information, PATH, ruby version installed
> and complete output of the issue for us trying to replicate and
> consider a bug.
>

This Windows 7 is fully patched from Windows Update:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

t:\devkit\devkit\msys\1.0.11>ruby --version
ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]

t:\devkit\devkit\msys\1.0.11>gem --version
1.3.5

t:\devkit\devkit\msys\1.0.11>PATH
PATH=C:\Program Files\JavaFX\javafx-sdk1.2\bin;C:\Program Files\JavaFX
\javafx-sdk1.2\emulator\bin;C:\Program Files\PC Co
nnectivity Solution\;C:\Program Files\Embarcadero\RAD Studio\7.0\bin;C:
\Users\Public\Documents\RAD Studio\7.0\Bpl;C:\Pro
gram Files\CodeGear\RAD Studio\6.0\bin;C:\Users\Public\Documents\RAD
Studio\6.0\Bpl;C:\Program Files\CodeGear\RAD Studio
\5.0\bin;C:\Users\Public\Documents\RAD Studio\5.0\Bpl;C:\Windows
\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows
\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server
\90\Tools\binn\;C:\Users\Public\Documents\RAD Stu
dio\6.0\Bpl;q:\Commands;q:\ruby\bin;c:\Program Files\Java
\jdk1.6.0_16\bin;q:\php;q:\ZendFramework\bin

The RC1 devkit containing msys-1.0.dll version 1.0.11 is the only
cygwin related executable. Actually the msys-1.0.dll is the only
executable that contains the error message and nothing outside devkit
loads msys. So, it must be it.

I remember that the pointer init_cheap prints out was 0.

The problem is volatile - msys.bat works today.

As for the Ruby version, I guess it is irrelevant since Ruby is not
involved in any way.

[Luis Lavena]

On Thu, Dec 3, 2009 at 6:19 PM, Octagon <g...@kaluga.ru> wrote:
>>
>
> This Windows 7 is fully patched from Windows Update:
>
> Microsoft Windows [Version 6.1.7600]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> t:\devkit\devkit\msys\1.0.11>ruby --version
> ruby 1.9.1p243 (2009-07-16 revision 24175) [i386-mingw32]
>

Where is Ruby installed? Based on the output of PATH, seems to me that
is in "q:\ruby\bin" while the devkit is in "t:"

Unless you extremely abuse of drive substitution (subst.exe) or you
modified the stub files for gcc, make and others, don't see how that
should work.

Also, looking at the PATH:

> t:\devkit\devkit\msys\1.0.11>PATH
> PATH=C:\Program Files\JavaFX\javafx-sdk1.2\bin;C:\Program Files\JavaFX
> \javafx-sdk1.2\emulator\bin;C:\Program Files\PC Co
> nnectivity Solution\;C:\Program Files\Embarcadero\RAD Studio\7.0\bin;C:
> \Users\Public\Documents\RAD Studio\7.0\Bpl;C:\Pro
> gram Files\CodeGear\RAD Studio\6.0\bin;C:\Users\Public\Documents\RAD
> Studio\6.0\Bpl;C:\Program Files\CodeGear\RAD Studio
> \5.0\bin;C:\Users\Public\Documents\RAD Studio\5.0\Bpl;C:\Windows
> \system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows
> \System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server
> \90\Tools\binn\;C:\Users\Public\Documents\RAD Stu
> dio\6.0\Bpl;q:\Commands;q:\ruby\bin;c:\Program Files\Java
> \jdk1.6.0_16\bin;q:\php;q:\ZendFramework\bin
>

I see a lot of references to RAD Studio and different versions.

I'm pretty aware that Delphi used to bundle a make binary that could
interfe with our own stub scripts.

Will be safer to cleanup the PATH and try to replicate.

> The RC1 devkit containing msys-1.0.dll version 1.0.11 is the only
> cygwin related executable. Actually the msys-1.0.dll is the only
> executable that contains the error message and nothing outside devkit
> loads msys. So, it must be it.
>
> I remember that the pointer init_cheap prints out was 0.
>
> The problem is volatile - msys.bat works today.
>

So perhaps, in your situation, something else was interfering.

> As for the Ruby version, I guess it is irrelevant since Ruby is not
> involved in any way.

More than the Ruby version I'm worried about the placement of it and
in relation to the DevKit.

[Octagon]

>
> I see a lot of references to RAD Studio and different versions.
>
> I'm pretty aware that Delphi used to bundle a make binary that could
> interfe with our own stub scripts.
>
> Will be safer to cleanup the PATH and try to replicate.
>

Since the error happens when Cygwin stack is initialized, I guess any
Cygwin related action has the same chances to hit the problem. I am
done with compiling gems for now, so I just run msys.bat.

I cleared the PATH and it changed nothing.

>
> So perhaps, in your situation, something else was interfering.
>

Evidently so. I do not have enough statistics yet, only an
observation.
Unfortunately, I do not remember how I got to Windows 7 when I got
the first errors, especially when the patched eventmachine failed to
compile as normal user and unpatched compiled OK. I have not looked
into the compilation process, possibly unpatched just does not use
Cygwin.

When all worked yesterday, I got to Windows 7 from cold start into
XP. Today I got into 7 from cold start and boot to Slackware and got
the error again:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x260000, State
0x10000
Q:\ruby\devkit\msys\1.0.11\bin\rxvt.exe: *** Couldn't reserve space

for cygwin's heap, Win32 error 0

Press any key to continue . . .

I made a cold restart of Windows 7 and everything works.

Athlon 3500+, Foxconn MS690M2MA

>
> More than the Ruby version I'm worried about the placement of it and
> in relation to the DevKit.
> --

The devkit used with Ruby is placed in q:\ruby as recommended. When
there is
a problem, it makes no difference if I use the devkit in ruby, or just
devkit it a
temporary directory, with or without ruby in the path.

[Luis Lavena]

On Fri, Dec 4, 2009 at 8:25 AM, Octagon <g...@kaluga.ru> wrote:
>>
>> I see a lot of references to RAD Studio and different versions.
>>
>> I'm pretty aware that Delphi used to bundle a make binary that could
>> interfe with our own stub scripts.
>>
>> Will be safer to cleanup the PATH and try to replicate.
>>
>
> Since the error happens when Cygwin stack is initialized, I guess any
> Cygwin related action has the same chances to hit the problem. I am
> done with compiling gems for now, so I just run msys.bat.
>

You shouldn't be starting msys.bat to compile gems.

msys will start a bash shell around your cmd.exe which will render
some path and access to some stuff useless.

That is the purpose of the DevKit stub batch files, to do the wrapping
without including the whole MSYS environment.

rxvt.exe is known to have issues on versions greater than XP.

Have you tried just "bash.exe" directly?

>
> Evidently so. I do not have enough statistics yet, only an
> observation.
> Unfortunately, I do not remember how I got to Windows 7 when I got
> the first errors, especially when the patched eventmachine failed to
> compile as normal user and unpatched compiled OK. I have not looked
> into the compilation process, possibly unpatched just does not use
> Cygwin.
>

EventMachine, patched or unpatched do shell to perform anything, so it
will not be the responsible of generating the cygwin fault.

> When all worked yesterday, I got to Windows 7 from cold start into
> XP. Today I got into 7 from cold start and boot to Slackware and got
> the error again:
>
>      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
> error 487
> AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x260000, State
> 0x10000
> Q:\ruby\devkit\msys\1.0.11\bin\rxvt.exe: *** Couldn't reserve space
> for cygwin's heap, Win32 error 0
> Press any key to continue . . .
>
> I made a cold restart of Windows 7 and everything works.
>

Dunno how other OS will be affecting this, is beyond my understanding,
but rxvt could have other issues with newer version of Windows.

On this side, trying to start msys.bat form either a 64bits or 32bits
command prompt generates a 0xc0000142 error on sh.exe

Starting bash.exe directly works.

>
> The devkit used with Ruby is placed in q:\ruby as recommended. When
> there is
> a problem, it makes no difference if I use the devkit in ruby, or just
> devkit it a
> temporary directory, with or without ruby in the path.

I hope you changed the stub files and fstab inside msys etc folder to
match the newer path.

[Alexey Borzenkov]

On Fri, Dec 4, 2009 at 2:25 PM, Octagon <g...@kaluga.ru> wrote:
>      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
> error 487
> AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x260000, State
> 0x10000
> Q:\ruby\devkit\msys\1.0.11\bin\rxvt.exe: *** Couldn't reserve space
> for cygwin's heap, Win32 error 0
> Press any key to continue . . .

Googling for the error led me to these:

http://code.google.com/p/msysgit/issues/detail?id=176
http://code.google.com/p/msysgit/issues/detail?id=133
http://www.madwizard.org/electronics/articles/winavrvista

Apparently rebased msys dll works for people.

> I made a cold restart of Windows 7 and everything works.

One day my Vista went kaboom beyond repair and I had to restore it
with factory image. Reinstalled cygwin and started having fork issues,
even though on previous installation worked fine. Since I couldn't
live without cygwin I had to move to Operating System with X in its
name (happened to be OS X), and now I'm a happy macbook owner for
almost a year. Alternative operating systems with X in their name seem
to work too (at least at work), so it beats me why developers would
choose Vista/7 over WinXP. :-)

P.S. On the other hand this showed me how fragile cygwin's fork
emulation really is. :-/

[Octagon]

On Dec 4, 10:59 pm, Alexey Borzenkov <sna...@gmail.com> wrote:
> On Fri, Dec 4, 2009 at 2:25 PM, Octagon <g...@kaluga.ru> wrote:
> >      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
> > error 487
> > AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x260000, State
> > 0x10000
> > Q:\ruby\devkit\msys\1.0.11\bin\rxvt.exe: *** Couldn't reserve space
> > for cygwin's heap, Win32 error 0
> > Press any key to continue . . .
>
> Googling for the error led me to these:
>

> http://code.google.com/p/msysgit/issues/detail?id=176http://code.google.com/p/msysgit/issues/detail?id=133http://www.madwizard.org/electronics/articles/winavrvista

>
> Apparently rebased msys dll works for people.
>

I had time for several reboots and found out that the problem can be
reliably duplicated (or I should better say reliably duplicated for
now) on my machine. After cold boot into Slackware and warm reboot
into Windows 7 Cygwin does not work. After cold boot into Windows 7 or
cold boot into XP and warm reboot into Windows 7 it works. When it
does not work, I can play with path, call bash/rxvt/gem in any ways,
run memory hungry apps, and nothing helps. Run As Administrator helps.
When it works, it similarly works whatever I do.

I believe this is the same issue that is described in the links Alexey
found. So, I guess we have to conclude that the "cannot allocate
stack" problem still may show up in Cygwin and that it may be solved
sometimes by cold reboot and/or run As Administrator. If there will be
some place for recommendations, I guess this should go there. If not,
no problem, the event must be a rare one.

Re: "Dunno how other OS will be affecting this, is beyond my
understanding". I do not get it either, but I also do not know all the
details of the modern AMD processor operation and motherboard secrets.
However, I am sure such things happen on Windows, maybe thanks to DRM
and secret motherboard chips presumably doing power conservation. Just
today I saw how absolutely nothing, including multiple soft reboots,
cures the loss of the ability to connect to FTP in active mode on XP
and how, after hours of frustration, a cold reboot fixes everything.