My game crashes on quit...

[hangt5]

Does anyone have any idea what would make a program crash when it quits?

My game is coded in Cocoa/Carbon, Using GLUT for window/event management.
If it matters i know the crash happens after glut calls the reshape function.

[BinarySpike]

I had trouble with my call to AglSwapContext.....
(over-stepped and array)

Check all your variables... (arrays and unions, need to be checked)
If you can't find anything wrong with the variables check function parameters...

[hangt5]

Sorry just to make myself clearer: When i quit my game, it crashes.

[belthaczar]

What does the crash log say?

[hangt5]

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x74676120

Thread 0 Crashed:
0 libobjc.A.dylib 0x908311ec objc_msgSend + 0xc
1 com.apple.CoreFoundation 0x90194378 __CFArrayReleaseValues + 0x188
2 com.apple.CoreFoundation 0x9019538c __CFArrayDeallocate + 0x3c
3 com.apple.CoreFoundation 0x90190cf0 CFRelease + 0x1e8
4 com.apple.CoreFoundation 0x90197f28 CFDictionaryRemoveAllValues + 0x200
5 com.apple.CoreFoundation 0x901a5fc8 __CFDictionaryDeallocate + 0x54
6 com.apple.CoreFoundation 0x90190cf0 CFRelease + 0x1e8
7 com.apple.CoreFoundation 0x90197f28 CFDictionaryRemoveAllValues + 0x200
8 com.apple.CoreFoundation 0x901a5fc8 __CFDictionaryDeallocate + 0x54
9 com.apple.CoreFoundation 0x90190cf0 CFRelease + 0x1e8
10 com.apple.CoreFoundation 0x901a8590 CFSetRemoveAllValues + 0x150
11 com.apple.CoreFoundation 0x901b2f54 __CFSetDeallocate + 0x54
12 com.apple.CoreFoundation 0x90190cf0 CFRelease + 0x1e8
13 com.apple.iokit.IOHIDLib 0x00640860 IOHIDDeviceClass::~IOHIDDeviceClass [unified]() + 0xc4
14 com.apple.iokit.IOHIDLib 0x00643a10 IOHIDIUnknown::release() + 0x40
15 com.apple.glut 0x8b834ec4 HIDCloseReleaseInterface + 0x80
16 com.apple.glut 0x8b837280 HIDDisposeDevice + 0x4c
17 com.apple.glut 0x8b8375f4 HIDReleaseDeviceList + 0x58
18 com.apple.glut 0x8b81c50c __glutShutdown + 0x18
19 libSystem.B.dylib 0x9002c7b8 exit + 0x58
20 com.apple.AppKit 0x92eae9c8 -[NSApplication terminate:] + 0x1f0
21 com.apple.AppKit 0x92e78224 -[NSApplication sendAction:to:from:] + 0x6c
22 com.apple.AppKit 0x92eada44 -[NSMenu performActionForItemAtIndex:] + 0x188
23 com.apple.AppKit 0x92ef22e4 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 0x68
24 com.apple.AppKit 0x92ef8c14 -[NSMenu performKeyEquivalent:] + 0x104
25 com.apple.AppKit 0x92ed7ccc -[NSApplication _handleKeyEquivalent:] + 0x124
26 com.apple.AppKit 0x92df53dc -[NSApplication sendEvent:] + 0xa5c
27 com.apple.glut 0x8b811cc4 -[GLUTApplication _runMainLoopUntilDate:autoreleasePool:] + 0x64
28 com.apple.glut 0x8b811e50 -[GLUTApplication run] + 0x118
29 com.apple.glut 0x8b82bd28 glutMainLoop + 0xa4
30 main.ob 0x000a54c4 main + 0xf0 (main.mm:836)
31 com.apple.myCarbonApp 0x000029ac start + 0x1c8
32 dyld 0x8fe1a558 _dyld_start + 0x64

[belthaczar]

hmmm...perhaps an array or dictionary is trying to release an object that for some reason doesn't exist anymore? try commenting out all of your dealloc methods and see if the problem persists.

[hangt5]

dont have any. Everything is carbon/c++ except a few calls to NSString. Im positive its not a cocoa thing.

Are there an instances where i would have to manually dealloc memory in c++?... Its amazing i have gotten so far into this project without really knowing the language.

[wadesworld]

The problem could be when trying to release a HID device as a result of _glutShutdown.

Are you doing anything with input devices?

Wade

[hangt5]

Nothing at all.

I isolated the problem... sorta.
I have an array dynamically allocate itself depending on how many 'objects' there are in a .obj file. When the file contains only 1 object i dont get the crash. Is there anything special i have to do when i dynamically allocate memory like that?

[wadesworld]

Can you show us how you allocate it and release it?

Wade

[hangt5]

wavefront *myObjects;
...

int nArrays = functionToFindOutHowManArrays();
myObjects = new wavefront[nArrays];


I wasn't sure when i was supposed to release it since i use it until my program quits.

[PowerMacX]

Does the wavefront class have a destructor? If so, try commenting it out.
Do you delete the myObjects array the right way (delete [] myObjects; )? Comment that line out too.
Still crashing?

[hangt5]

I never deleted the myObjects array so i added the deletion statement after glutEnterMainLoop(); and i still get the error.

My program returns to main() once the the glutMainLoop is finished right?

The wavefront struct holds 4 or 5 pointers to dynamically allocated arrays. Do i need to delete each of these as well?

[PowerMacX]

Each wavefront should probably be responsible for releasing all the memory/objects it allocated, and should do so in it's destructor (structs can have destructors too, class & struct are basically the same for C++, the only difference being that class defaults to private member variables and struct to public)

Anyway, if you don't release your objects before the application exits the system should take care of it, so for now you should comment all the "memory release" portions of your code. Start commenting stuff out until it doesn't crash to find exactly what causes it.

Does the crash occur if you run it in the debbuger?

Perhaps it's just some glut callback you forgot to set?

[wadesworld]

Do your objects contain CoreFoundation collections such as CFString, CFArray, etc? That's where the crash is coming from.

Although it's always good practice to delete something you allocated, with an allocation using new or malloc, it won't cause a program crash if the object is not deleted. Maybe you're sending a CFRelease to the elements of a CFArray?

Wade

[hangt5]

Each wavefront should probably be responsible for releasing all the memory/objects it allocated, and should do so in it's destructor (structs can have destructors too, class & struct are basically the same for C++, the only difference being that class defaults to private member variables and struct to public)

Anyway, if you don't release your objects before the application exits the system should take care of it, so for now you should comment all the "memory release" portions of your code. Start commenting stuff out until it doesn't crash to find exactly what causes it.

Does the crash occur if you run it in the debbuger?

Perhaps it's just some glut callback you forgot to set?

1.) I don't have any "memory release" code. So far everything i use i need till termination...

2.) it does not crash the debugger

3.) if it had anything to do with glut the crash wouldn't be dependent on how many 'slots' i allocate the array with. Remember if I only allocate the array with one slot it doesn't crash.

[hangt5]

Do your objects contain CoreFoundation collections such as CFString, CFArray, etc? That's where the crash is coming from.

Although it's always good practice to delete something you allocated, with an allocation using new or malloc, it won't cause a program crash if the object is not deleted. Maybe you're sending a CFRelease to the elements of a CFArray?

Wade

Nope

typedef struct
{
float x,y,z;

}vertex;

typedef struct
{
int vIndex[4];
int tIndex[4];
int gId;
}face;

typedef struct
{
char texName[16];
int gId;

}group;

typedef struct
{
tgaTexture *textures;
}texture;

typedef struct
{
group *groups;
int nVertices, nTVertices, nFaces;
vertex *vertices;
vertex *tVertices;
face *faces;
texture *textureWrapper;

}wavefront;

[hangt5]

Well i cant even begin to explain what the problem was but i somehow managed to fix it.

Every frame i loop through my array of OBJ's and display them to the user. I first check if the object has a textureID... if(object.textureWrapper[object.faces[count].gId].textures[0].textID)
if it does i use texturing if it doesn't i don't.

I noticed my app crashed if i didnt give my objects textures (different crash then the one this thread is about). This was because i dont allocate textureWrapper unless i give an obj a texture. So checking for textID IN textureWrapper when it was never allocating it was crashing my program. I changed the if to simply check for textureWrapper in an attempt to fix the second bug and for some unexplainable reason it fixed both bugs.

WHY the glutMainLoop was executing AFTER my log says its stoped i don't know. BUT it fixed my problem and im happy.

Thanks you all for your help. I really appreciate your time. Hopefully some day soon il have something to show the community.

:)