Open2x Toolchain, Ld, Memory Stack?

[TrevorBradley]

Hi there... things going well on my C++ SDL project. I'm still targeting release for the Pandora, but it's possible I might be able to release a version for the GP2X.

I've managed to compile my game statically using the open2x toolchain, but there are still consistent crash bugs I believe might be related to memory. My program at present needs about 12MB of memory.

I notice I get a crash at runtime if I compile on Windows using Cygwin. I've managed to make these problems going away by passing the command line option "-Wl,--stack,10000000" to g++. I could also make them go away by reducing my memory usage to about 8 MB. I don't need any such parameters to compile and run on x86 linux.

A bit of research indicates these parameters are passed to the linker ld, and that the parameters needed are OS specific. I was hoping I could pass these parameters, or something similar to the open2x toolchain, but looking at open2x' ld --help command doesn't reveal anything obvious.

If I want to compile a C++ program using the GP2X toolchain that wont crash with a segmentation fault when allocating a larger amounts of memory, what command line parameter should I pass to it?

It's possible my problems have to do with something else .other than memory.. If so it's going to be painful to debug on an F200..

Thanks in advance for your replies! The GP32x community has been a great help in getting this project off the ground.

 

[skeezix]

uh, you shouldn't need an enormous _Stack_ to avoid crashes; you've probabyl got a buffer overrun and you're masking it by making a giant stack or something.

malloc() (and new() etc) are against 'heap', the dynamic memory pool; stack is for 'autos', things allocated temporarily when you got "int x" say. (ie: they're present only for their scoped life, wheres malloc/new create things until you specificly remove them.)

Didnt' read your post that carefully, but if you're using SDL you should not need any really esoteric options that are platform specific.

My total guess (no code to look at etc) is that you're allocating some arrays and blowing past their end, or allocating with malloc/new and b lowing past the end, and corrupting something. Its very easy to do this, and can be hard to find. (There are tools, like 'efence' and so on.)

jeff

 

[ledow]

Valgrind has a heap checker - I often use it and it's memory allocation checker to find such problems.

And I have to agree with skeezix - this sounds like a stack problem, not a particular compiler or platform by the sound of it. It's just that the GP2X has less stack and so causes these sorts of problems faster.

 

[kevcal]

You could look at /proc/meminfo - the 'MemFree' line - that has helped me spot memory errors that I probably wouldn't normally have the time to test for.

 

[senquack]

You could also switch to using a garbage collecting library and that would allow you to never issue a single free/delete ever again. It would take over the duties of determining when to deallocate memory. This library does work on the GP2X (I have used it).

You should also look through your code by hand to look for obvious errors. One time I had a very difficult problem to track similar to yours that was caused by initializing SDL video twice.