Weird SDL Crash

Member
Posts: 70
Joined: 2004.06
Post: #1
I've been writing a game in SDL lately, and everything has been working well. I made a ParticleSystem class today, and once it was finished I declared a variable of that class in my game manager class.
It then started crashing, so I looked in the crash log. This is some of what it contained:
Quote:Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbfe15030

Thread 0 Crashed:
#0 0x00005390 in SDL_main ((null):18)
#1 0x00005014 in -[SDLMain applicationDidFinishLaunching:] (SDLMain.m:196)
#2 0x97dfab40 in _nsNotificationCenterCallBack
#3 0x9016847c in _postNotification
#4 0x90165b90 in _CFNotificationCenterPostLocalNotification
#5 0x9318a8d0 in -[NSApplication _sendFinishLaunchingNotification]
#6 0x931616d0 in _requiredAEEventHandler
#7 0x91b56570 in aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned long, unsigned char*)
#8 0x91b590cc in dispatchEventAndSendReply(AEDesc const*, AEDesc*)
#9 0x91b56478 in aeProcessAppleEvent
#10 0x96a83778 in AEProcessAppleEvent
#11 0x9308dec8 in _DPSNextEvent
#12 0x9309ff78 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#13 0x930b1b48 in -[NSApplication run]
#14 0x00004f68 in CustomApplicationMain (SDLMain.m:176)
#15 0x00005360 in main (SDLMain.m:277)
#16 0x00004680 in _start (crt.c:267)
#17 0x00004500 in start

I thought that looked odd, because it looks like it is encountering the error while on line 18 of a "null" file during SDL's initialisation. Is this "null" file one of the files inside the framework or something?

Anyway, I tried using the debugger and set a breakpoint on the first lines of the application's main() function. It started debugging, and then said it recieved EXC_BAD_ACCESS. The red line to show what line execution was currently at was pointing to the opening brace of main(). So, the crash is occuring before I even execute a single line of my code.
I tried removing the variable declaration for my ParticleSystem, and the crash disapeared. I added another variable declaration, not another ParticleSystem but an array of 1000 Sprite classes. This also caused a crash.
It started to look suspiciously like a memory corruption problem.

I tried making the offending ParticleSystem variable a pointer and allocated memory for it using new in the game controllers constructor, and the game didn't crash. Interesting.

I gave the binary to someone running 10.3, and it didn't crash (even though the same binary crashed on my 10.2 system). Evidently, the stack on 10.3 is a lot larger than on 10.2. This knowledge, combined with the debugger showing that execution did in fact reach the opening brace (which I expect is where memory for the function's variables is allocated) makes me wonder if I simply have over-stepped my memory allocation and tried to take more memory than the stack has available.

If that is the case, then I would think it can be fixed simply enough by declaring pointers to the variables and then allocating memory for them myself rather than expecting the stack to house everything for me. Is that correct?
Or is it something else going wrong? I wouldn't expect a major bug in SDL, and the crash does happen depending on my code even though none of it executes, so it seems likely that I've outgrown my stack, if that's possible.

Can someone confirm this?
Quote this message in a reply
Member
Posts: 70
Joined: 2004.06
Post: #2
More (fairly decisive, IMO) information:
I decreased the maximum number of particles and emitters, thereby decreasing array size in my ParticleSystem class, and the crash disapeared. I also did a sizeof() on the ParticleSystem class, and it returned 61684 which is quite large. I decreased the number of particles significantly, so the size required by the manager would have previously been gigantic.

I am now almost positive that I am right and the crash is due to greedy memory allocation on my behalf. Time to convert everything to pointers...
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #3
SOUR-Monkey Wrote:I am now almost positive that I am right and the crash is due to greedy memory allocation on my behalf. Time to convert everything to pointers...
Before you get too carried away with allocating arrays with new, you might want to consider using STL vectors. They're easier and safer to use, and they're just as efficient as plain arrays if you use them properly.

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
STL vectors are only helpful if he's silly enough to be using C++ Wink

NCarter Wrote:and they're just as efficient as plain arrays if you use them properly

that's what they like to make you think... have you read the resulting assembly recently?
Quote this message in a reply
Moderator
Posts: 365
Joined: 2002.04
Post: #5
OneSadCookie Wrote:STL vectors are only helpful if he's silly enough to be using C++ Wink
Quite right:

SOUR-Monkey Wrote:I tried making the offending ParticleSystem variable a pointer and allocated memory for it using new in the game controllers constructor
Rasp

Quote:that's what they like to make you think... have you read the resulting assembly recently?
Well, they're close enough for most purposes. You can always use the vector for memory management, then iterate over it with a pointer instead of using the index operator. It also works better if you use a compiler which optimises instead of producing spaghetti. Wink

Neil Carter
Nether - Mac games and comic art
Quote this message in a reply
Member
Posts: 70
Joined: 2004.06
Post: #6
Yes Keith I am silly enough to be using C++. To make up for it, next time I've got free time I'll learn Ruby Rasp

I'm at school right now, so I'll have a look at these STL vectors and see what their deal is.
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #7
OneSadCookie Wrote:STL vectors are only helpful if he's silly enough to be using C++ Wink

NCarter Wrote:and they're just as efficient as plain arrays if you use them properly

that's what they like to make you think... have you read the resulting assembly recently?

Ruby is faster? Rolleyes Did you look at the assembly? Oh, that's right... there is no assembly... Wink
Quote this message in a reply
Post Reply