Issue with Visual C++ 2010 (Express) External Tools command_问答_开发者

I posted this on SuperUser...but I was hoping the pros here at SO might have a good idea about how to fix this as well....

Normally we develop in VS 2005 Pro, but I wanted to give VS 2010 a spin. We have custom build tools based off of GNU make tools that are called when creating an executable.

This is the error that I see 开发者_开发知识库whenever I call my external tool:

...\gnu\make.exe): *** couldn't commit memory for cygwin heap, Win32 error 487

The caveat is that it still works perfectly fine in VS2005, as well as being called straight from the command line. Also, my external tool is setup exactly the same as in VS 2005.

Is there some setting somewhere that could cause this error to be thrown?

From problem with heap, win32 error 487 :

Each Cygwin app gets a special heap area to hold stuff which is inherited to child processes. Eg. all file descriptor structures are stored in that heap area (called the "cygheap"). The cygheap has room for at least 4000 file descriptor structures. But - that's the clue - it's fixed size. The cygheap can't grow. It's size is reserved at the application's start and it's blocks are commited on demand.

For some reason your server application needs all the cygheap space when running under the described conditions.

A possible solution might be found in Changing Cygwin's Maximum Memory:

Cygwin's heap is extensible. However, it does start out at a fixed size and attempts to extend it may run into memory which has been previously allocated by Windows. In some cases, this problem can be solved by adding an entry in the either the HKEY_LOCAL_MACHINE (to change the limit for all users) or HKEY_CURRENT_USER (for just the current user) section of the registry.

Add the DWORD value heap_chunk_in_mb and set it to the desired memory limit in decimal MB. It is preferred to do this in Cygwin using the regtool program included in the Cygwin package. (For more information about regtool or the other Cygwin utilities, see the section called “Cygwin Utilities” or use the --help option of each util.) You should always be careful when using regtool since damaging your system registry can result in an unusable system. This example sets memory limit to 1024 MB:
regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1024
regtool -v list /HKLM/Software/Cygwin
Exit all running Cygwin processes and restart them. Memory can be allocated up to the size of the system swap space minus any the size of any running processes. The system swap should be at least as large as the physically installed RAM and can be modified under the System category of the Control Panel.

It wouldn't hurt to ensure that the maximum size of your windows swap file is large enough.

To summerize : The environment doesn't allocate enough heap space for the cygwin executables. For some reason the problem is more acute with VS2010 Express. You need to either fix the environment, or use another Linux port than cygwin, or use Microsoft utilities.

From the cygwin email lists it looks like other people have run into similar situations, even when not running via Visual Studio, to which they've found that the solution is often to play with Cygwin's maximum memory settings:

http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html

(note: it's worth reading this conversation, from above, about some values that did and didn't work).

Others have also reported issues with Anti-Virus software (recommendation is to unload from memory for some reason), and possibly also compatibility settings (try with it set to XP) which can affect cygwin in certain cases. See: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=377066

As for Visual Studio: Are you on a 64bit machine and if so are you usually running the tool in a 64bit environment?

I've found that because Visual Studio 2010 runs in 32bit, tools launched from it are launched as 32bit processes (for a good illustration of this, add "cmd" as a tool). I'm not sure why this wouldn't be affected on 2005 (unless 2005 lets the system launch the process (64bit) and 2010 handles it itself (32bit)).