I'm going CRAZY!!! Random crashes without reason

This has got to be the weirdest thing EVER! I'm trying to make a game with a full screen graphics context. After getting that out, and trying to display a menu, it worked fine for a little while. Then, suddenly, it started crashing. Without changing anything major. It keeps on saying that I was accessing freed memory and the crash reporter usually gives me the line where I call glGenTextures, the debugger stopps where I free a C string. The problem is, I don't have anything else where I free it! Here's a walkthrough of what I did trying to track down the problem:

This C string is one that I'm constructing to open a texture. I malloc it, copy the bundle string, then concatenate the rest of the path. After that, I feed the string into my open TGA method, and free the string. The string is accessed twice: once to check to make sure it's not NULL, and once to open the file. That can't be a problem, but I comment it out anyway. Next, it crashes citing where I delete the TGA file after loading the texture (using glTexImage2D), saying where I set the pointer to NULL. Ok, I take that out. It then crashes pointing to the end of the function. I say WTF??? and comment out where I actually free the data, and it works. It also works when I just comment out my deleteTGA function. Neither of those should have done anything. The this class also contains Font classes which instantiate before hand it actually gets to the crash. It has a nearly identical method of opening my font texture, and if I comment out the string free and texture delete there, it usually works as well. At one point, I commented out all of my texture loading function calls, and it says I accessed freed memory when assigning an integer! (by the line number it gave me)

It gets even weirder. I commented out my capture display function calls, and ran through the debugger. It went through the instanciation of the menu class this is crashing in, it starts instanciating the fonts, goes to the malloc of the C string for accessing the font texture, then completely dies. When I look at the function calls, it suddenly jumped past all not only that font instanciation, but all the rest of them as well to where I freed the C string for opening the texture for the texture after all that is done.

When I comment out all the frees and deletes, it runs, but doesn't load one of the textures.

As a final test, I went into main.m, took out NSApplicationMainLoop, instanciated my controller, slept for 20 seconds, then quit. Lo and behold, it worked perfectly! Loaded all the textures and displayed the graphics perfectly, no malloc errors, NOTHING! I take it back out, and it crashes.

Edit: almost forgot to mention: at one point, I put in a print call, and it didn't crash! One of the textures didn't load, but it didn't crash. I took out the print statement, and it crashed again... Talk about weird. Not even accessing anything, just "cerr << "here\n";"

Here is all relevent code. I'm at a complete loss. I've been at this all day without avail. Hopefully somebody here with more cocoa experience can help me.

(mainWindow and eventView were added after trying most of this stuff, but made no difference)

Wow. I just found it. And it was not where I suspected. In my open TGA function, I accidentally put in the wrong thing for the size for my call to malloc (the pointer instead of the type, which have similar names). It worked all other times, purely by luck, so I didn't think that would be it. Malloc debug actually caught that for me: It printed out that I was freeing past the malloc, then I put in print statements, and then it led me to there. Wow. The symptoms certainly were weird, though...

Whenever you have random crashes, odds are its a memory problem, whether by trying to follow an uninitialized pointer, trying to access an item in an array that doesn't exist (out of bounds), having two pointers that point to the same thing then trying to delete both of them, etc.

The reason it's random is because the OS chooses a slice of RAM each time for your program to use (I think it's called the stack space?), so your faulty code was using a different section of RAM each time.

This was malloced onto the heap. I confess I don't have much experience (I just started learning how to program last year), so I didn't know that it was a sign of memory problems. Made since once I found out that was the problem. At least the laws of math and physics weren't breaking...