Couldn't Allocate Heap, win32 error ...

[BroOfTheSun]

Hey, I frequently get this error when I compile. Could someone help me understand what this error is? It happens sometimes when I try to compile. When I see it, I just recompile until the build completes successfully.

error message:

2 [main] ? (684) C:\sgdk\bin\make.exe: *** fatal error - C:\sgdk\bin\make.exe: *** couldn't allocate heap, Win32 error 0, base 0x8D0000, top 0x8F0000, reserve_szie 126976, allocsize 131072, page_const 4096

5 [main] make 2700 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11
make: vfork: Resource temporarily unavailable
make: *** Deleting file 'out/src/LevelTest.o'
...

Is my computer running out of memory when compiling?

NM..found an old thread
viewtopic.php?t=1196&highlight=heap

[Stef]

Definitely a bug with the GCC included in SGDK :-/
Hopefully you can get your file compiled by trying several time but indeed an annoying bug !

[djcouchycouch]

I just got this today, too, trying to move my SGDK projects to a Windows 7 machine. I was running on XP before.

Edit: Windows 7 machine, not Windows 8

[Stef]

The bug does not happen on XP ? maybe someone can try to re-compile it on a win7 system. I'm now used to push compilation until it get done but i understand that is an annoying bug in the compiler.

[djcouchycouch]

The bug does not happen on XP ? maybe someone can try to re-compile it on a win7 system. I'm now used to push compilation until it get done but i understand that is an annoying bug in the compiler.

It never happened on XP on my machine. I dunno if recompiling SGDK would work.

What I could find about the problem was that it might be caused by Windows' Address Space Layout Randomization (ASLR), introduced in Vista. I tried disabling it manually using some instructions I found but that didn't work.

The other main thread I found was that some programs might be interfering with Cygwin, as noted in the Big List of Dodgy Apps. But I don't know if internally SGDK uses any Cygwin stuff.

Also about Cygwin, when it comes to ASLR, there was mention about "rebasing" it and for some it fixed the problem.

I don't know if any of the above are the problem, but that's all I could really find about the error message.

djcc

[Stef]

SGDK uses a mingw32 version of GCC, so not the cygwin distribution... When i spoke about recompilation, i meant recompiling the compiler and so GCC and binutils on windows 7. I probably compiled them on a XP platform back in time but t should not make any difference.

[djcouchycouch]

SGDK uses a mingw32 version of GCC, so not the cygwin distribution... When i spoke about recompilation, i meant recompiling the compiler and so GCC and binutils on windows 7. I probably compiled them on a XP platform back in time but t should not make any difference.

I was thinking about looking into this during the holidays. Stef, you think rebuilding the compiler would be a possible solution? Where can I find instructions for how you usually build it for the sgdk?

[Stef]

You basically need to compile GCC for x86 host and m68k-elf target and that is
But definitely using newer versions of GCC will result in poorly code generation :-/

[djcouchycouch]

I got scared off by the instructions on how to compile GCC, so I tried something else

Setting the compatibility mode properties for make.exe and to Windows XP (Service Pack 3) seems to fix the problem. Before setting it, I get the error every second time I compile. After I set it, I compiled over a dozen times with no problems. I turned it off again and got the problem reappeared. It it appears to work, for me at least.

So I think that's a workaround. Try it out and let us know.

[Stef]

I got scared off by the instructions on how to compile GCC, so I tried something else

Setting the compatibility mode properties for make.exe and to Windows XP (Service Pack 3) seems to fix the problem. Before setting it, I get the error every second time I compile. After I set it, I compiled over a dozen times with no problems. I turned it off again and got the problem reappeared. It it appears to work, for me at least.

So I think that's a workaround. Try it out and let us know.

Oh i never tried that ! Nice finding I will test that asap !

[KanedaFr]

You basically need to compile GCC for x86 host and m68k-elf target and that is
But definitely using newer versions of GCC will result in poorly code generation :-/

Hi, based on these words and on mike's work (viewtopic.php?f=19&t=2269), can you tell use which GCC version to use ?
And what do you mean by "poorly code generation" ? did they change optimization in some newer version ?

perhaps a script like mike's one could be written to anyone wanting to try it...
the only thing I have as a reference is http://gnutoolchains.com/building/

[Stef]

Hi, based on these words and on mike's work (viewtopic.php?f=19&t=2269), can you tell use which GCC version to use ?
And what do you mean by "poorly code generation" ? did they change optimization in some newer version ?

perhaps a script like mike's one could be written to anyone wanting to try it...
the only thing I have as a reference is http://gnutoolchains.com/building/

I think i used similar instructions to build my GCC toolchains
But yeah definitely newer GCC produces poor code for m68k target, that is why i keep an old GCC 3.4.6 in SGDK.
I think the version which produce best code for m68k is around 2.8.xx but that is definitely too old and some nice compiler features are missing.
I think version 3.4.6 is "good enough", 4.X or new (5.X) produces poorly optimized code and generally later versions are worst :-/ That is just due to GCC adapting the code generation structure to newer CPU architecture which basically broke optimization done for older architecture as the 68000.

[KanedaFr]

ok, thanks for the info

perhaps i'll say something stupid but do you think I can use the last GCC/GDB for debug and the last 3.x version for release ?
or the differnce betwen the 2 codes will create more problems (like code working on a version but not on another) ?
(yes, still trying to find the best way to handle GDB on KMod!)

[Stef]

That should be a doable solution Normally code should work on both version without any problems, newer GCC will just be slower :p

[Ced2911]

Same error for me (windows 10 64) also libmd.a isn't up to date (currentZ80Driver missing refernces issues)