Strange SDL problem

DJBlufire
Unregistered
 
Post: #1
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
Quote this message in a reply
DJBlufire
Unregistered
 
Post: #2
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...
Quote this message in a reply
w_reade
Unregistered
 
Post: #3
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.
Quote this message in a reply
DJBlufire
Unregistered
 
Post: #4
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 this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #5
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...

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Strange lighting problem Duncanla 14 6,006 Mar 1, 2005 02:43 PM
Last Post: Duncanla
  strange color problem leggo 12 5,932 Aug 27, 2004 08:36 AM
Last Post: leggo