Re: [Mingw-users] Out of memory for cc1plus

[Edward D. <eld...@tr...>]

On 12/24/2014 11:25 AM, Eli Zaretskii wrote:
>> From: Edward Diener <eld...@tr...>
>> Date: Wed, 24 Dec 2014 02:40:42 -0500
>>
>> I am seeing an out of memory message of:
>>
>> "cc1plus.exe: out of memory allocating 65536 bytes"
>>
>> when compiling code using mingw and gcc-4.8.1-4.
>
> Can you look in the Task Manager or some other similar tool what is
> cc1plus's memory footprint at that point, or just before that?

Your astute guess is correct. Using gcc-4.8.1-4 the code being compiled 
shoots up at one point to use as much as 1.3 GB of memory before it 
gives the out of memory error. When I compile the same code with 
gcc-4.7.2 the maximum memory being used is approximartely 57 MB. That is 
quite a difference and definitely suggests a huge memory leak of some 
kind or some other compiler/preprocessor snafu.

In both cases the code being compiled is just preprocessor macros and no 
C++11 features, other than variadic macros, are even being remotely 
used. In fact the entire program giving the out of memory error is just 
a dozen object-like macros and 4 BOOST_TEST lightweight test macros 
enclosing some macros in my VMD library. While the macro expansion of my 
macros are pretty heavy duty it should never take anywhere near 1.3 GB 
to expand them, as gcc-4.7.2 shows.

>
>> Or might this just be a problem in Windows with the mingw
>> implementation of gcc ?
>
> Unlikely.  There's no such thing as "the MinGW implementation" of GCC,
> it's just a Windows compile of the stock GCC code.

Got it.

>
>> I am compiling under Windows 7 Ultimate with 8 GB of real memory, so I
>> do not think this has anything to do with my hardware itself.
>
> Note that a 32-bit compiler is still limited to 2GB, even on a 64-bit
> OS.

Of course but one would hardly expect any compilation to use 1.3 GB of 
memory.

I could report this on the gcc bugzilla tracker but reproducing it using 
my VMD library, although it is public on Github, will be fairly 
complicated task ( the latest modular Boost must also be downloaded and 
setup from Github ) for whomever handles the bug. I was hoping this sort 
of problem, based on what seems to me to be a large-scale memory leak, 
would be known for these later versions of gcc and I could find a 
workaround.