Too much class code = Class doesn't load?

[Aerolite]

Hey again all,

This one I can't see being solved by myself alone, so I'm asking once again for help. To be honest, I'm not really sure how to explain it...
The game I'm currently working on is a heavily class-based project (I.e. everything is a class object), however I'm finding that for no apparent reason if too much code is added to any class, then I essentially get two black screens. No backgrounds, no sprites, no nothing. Thing is, code is still running... Its like the class that handles my visuals is simply breaking, or not loading or something. If I run this .nds through ensata, I get a "Stopped due to abort or undefined instruction in ARM9" error.

If I say, go back into my code and stop my WorldInfo class from being created (This class contains all the necessary code for the game world/level loading), then while I get no level, my sprites will show up. Alternatively, if I stop my InputHandler class from being loaded (a small input wrapper), No$GBA briefly shows a background, before branching to a section of code that is essentially zeroed-out...

Hell I don't really even know what I'm asking here... Are there any compiler issues when dealing with classes?? I mean, I'd be happy to post some code, but the truth is I wouldn't know what to post aside from the whole project (which I'm not wanting to do in a public forum, as you may expect).

I had an old (horribly coded) class-less version of this same game that would not have any errors like this, and had more overall code in it. However, it was also based on a much older version of libnds, so maybe that had something to do with it?

Is this a known issue? Can it be fixed? I'm at wits-end here, lol.

[WinterMute]

If you have the means to run on hardware then calling defaultExceptionHandler(); as early as possible may tell you if your code is blowing stack or writing to memory it shouldn't. Something to remember is the DS has only 16k of stack space available so large local arrays will kill you.

Checking the map file generated by the build process will tell you how much memory you're using, look for the __end__ symbol and subtract that address from 0x02400000. It's possible you're running out of RAM, something that's unfortunately rather easy to do with C++.

devkitARM compiled nds code won't run in Ensata at all, that's actually an official emulator designed only for use with official SDK code.

Another possibility is alignment, it's best to make sure your data arrays and any 32bit numbers in structs are 32bit aligned - ARM does peculiar things with misaligned reads.

[Hyperlisk]

Hey, I think I'm experiencing an issue similar to this. I'm trying to port over V8, Google's JavaScript engine, but linking with my lib causes nothing to happen. I get white screens in NO$GBA and on hardware as well. If you'd like to try it out for yourself, here's a link to the lib I built. Sorry it's so big, I built it with -O0. And here's some test code. Notice it never calls any libv8 specific things in it. Sorry to kinda hijack this thread, just ignore me if it seems too unrelated.

[Aerolite]

Sorry I haven't written back before now - I've been alittle busy.

Well defaultExceptionHandler() doesn't show anything abnormal, but the weird thing is if a have a call to defaultExceptionHandler() then my classes all load, albeit with obvious memory corruption... Taking that call away again results in two black screens...

The __end__ symbol subtracted from 0x02400000 yields 3,834,784 (0x003A83A0), which is obviously still in the clear (just, lol)

I'll bare that in mind with Ensata from now on, although I have run libnds code through it before with no issues... Fluke?

By this stage I'm thinking its an alignment issue, however I'm not 100% sure how I can fix it... Should I add an "__attribute__((aligned (4)))" to each of my class declarations? This is a new issue for me, so please forgive any obvious n00bness.

[Aerolite]

So er.. Anything else it could be? I still haven't solved this...