Strange SDL problem
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
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
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...
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.
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.
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.
Possibly Related Threads...
Thread: | Author | Replies: | Views: | Last Post | |
Strange lighting problem | Duncanla | 14 | 9,706 |
Mar 1, 2005 02:43 PM Last Post: Duncanla |
|
strange color problem | leggo | 12 | 9,744 |
Aug 27, 2004 08:36 AM Last Post: leggo |