iDevGames Forums
Strange SDL problem - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: Strange SDL problem (/thread-6727.html)



Strange SDL problem - DJBlufire - Sep 23, 2003 10:43 PM

How could a call to an SDL function like this suddenly break? It's worked before... the only thing that has changed is that I put in an OBJ file loader.

SDL_PollEvent(&event);

It's a runtime error, "EXC_BAD_ACCESS", and in the console it says

Code:
*** malloc[760]: Deallocation of a pointer not malloced: 0x1954a00; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug



Strange SDL problem - DJBlufire - Sep 23, 2003 10:50 PM

Hmm... seems that when I comment out my model loading function, it works fine. But I don't see how that function would cause a problem in the SDL library? Maybe out of memory or some sort of overwriting of memory? My code doesn't look like it has any leaks...


Strange SDL problem - w_reade - Sep 24, 2003 12:28 AM

MallocDebug will help you be a bit more confident that you're not leaking somewhere... it's absurdly easy to miss a leak if you're just inspecting by eye.


Strange SDL problem - DJBlufire - Sep 24, 2003 07:36 AM

Yep, you were right... turns out I wasn't allocating enough memory for the various data members of my model class. Strange that a problem would pop up somewhere completely different though.


Strange SDL problem - MattDiamond - Sep 24, 2003 09:09 AM

Quote:Originally posted by DJBlufire
Yep, you were right... turns out I wasn't allocating enough memory for the various data members of my model class. Strange that a problem would pop up somewhere completely different though.


Quote:Originally posted by DJBlufire
Yep, you were right... turns out I wasn't allocating enough memory for the various data members of my model class. Strange that a problem would pop up somewhere completely different though.


Not so strange, unfortunately. Since the memory heap is used globally, side effects can be global. Of course we'd prefer it to fail right where the error is, but memory errors are notorious for popping up somewhere else. And the symptoms can also be unpredictable. The value of tools like MallocDebug is that they can expose memory errors closer to the root cause.

The moral is, if you even suspect a memory error, head straight for the tools. And a good case can be made for using the tools even if you aren't aware of any problems in your program whatsoever. For example, I had a memory error in my old game 3D Brick Bash that was in there for many years (I think a pointer was allocated using malloc and freed using DisposePointer, or perhaps it was the other way around.) It didn't cause problems until several versions of MacOS later; I made a benign change elsewhere and started getting strange behavior. Just changing the order of some statements fixed it, but I eventually tracked it down to the real cause.

Which reminds me to run MallocDebug on my current project, just on the off-chance that it catches something...