Help tracking down “EXC_BAD_ACCESS”

Notice that the app was built using the 3.0 SDK templates.
It seems that the error occurs when I rebuilt it, as is for 2.2.1 SDK as the base.
When built wiht the base set to 3.0, the error does not occur.

I suspect the problem lies in some difference in the templates, but have no
proof of this at present. I was setting self.delegate to nil in viewDidUnload as
cleanup, but am not sure it is necessary.

The stack hints at maybe a problem in releasing a pointer to my scene object
but that should only be released if the MainView object is released, unless I
have an alloc/release mismatch releasing too many times. That will be my
next check.

Thank you etresoft for the info. My stack tracing isn't so hot yet with Xcode/gdb/objective-C.
I'm just starting to get the hang of it. It's possible that it's caused by direct access to some
pointers, field=value; vs. self.field = value doing a retain. I will be doing a scour of my
entire project due to that.

If that clears it up, then your information is likely spot on.

Guess this happens when one is rushing to add the next phase without dotting the i's first.
I'm just so proud that I have all the game and reset logic working so quickly, that i may have
cut a few corners. It's time to download Clang and find out how to use it.

Then get back to work on changing user defaults and config info in-app, and figure out
how to best save current state so I can reload and continue from where the user left off.

By current version do you mean 3.2 or 3.1.3 ?

Does 3.2 require Snowleopard ?

I've not upgraded to 10.6 yet....

I haven't finished my tidying up yet, but I agree with what you said about the stack trace. However, mainView is only ever deallocated when the game is completely finished, unless somehow there isn't enough memory and it needs to be deallocated while the flipsideView is displayed. The only timer events are the animations for the modal dialogues, which is exactly when the error is occurring.

By rushing, I meant to complete all the major aspects of my program, not rushing to bring up 10.6 or even to upgrade to XCode 3.2. Thanks again for explaining the stack trace. Now, looking at it, I don't know why I didn't see it, except I haven't done enough of them lately to be comfortable.

I'll post back to this thread when I've made progress. (and mark replies as answered as well).

Quick memory question on this... in several places I have code such as:

 self.currentSceneKey = [myScenes.sceneKeys objectAtIndex:sceneIndex];
 NSDictionary* myScene = [myScenes.scenes objectForKey:currentSceneKey];
 if (myScene) {
 self.currentSceneName = [myScene objectForKey:@"Name"];
 self.currentSceneNumber = [myScene objectForKey:@"Number"];
 self.currentSceneTableau = [myScene objectForKey:@"Tableau"];
 }

Line 1, copying a string from a dictionary, using self.field accessor with retain, OK

Line 2, temporary dictionary so I can retrieve 3 strings in lines 4-6
Does line 2 need to be alloced and inited with objects, and then released?

Second case, I access data from a string, and I believe from what I read, the substring returned will be auroreleased and an extra retain may be put on the original string until the release, but this construct appears in context in several places, and I don't really know if I should be doing allocs and inits, or if that is overkill.

for (int i=0; i<boardWidth; i++) {
 for (int j=0; j<boardHeight; j++) {
 NSString* imgKey = [currentSceneTableau substringWithRange:NSMakeRange(((jboardWidth)+i)3,2)];
 NSString* newKey = [myPieces.backgrounds objectForKey:imgKey]; // use board background
 UIImage* img=[myPieces.figures objectForKey:newKey]; // get image
 [img drawAtPoint:CGPointMake(i*cellSize, j*cellSize)];
 }
}

imgKey is a 2 character NSString* as is newKey, each used jut to retrieve the correct image from the dictionary, which is then drawn. Is this OK, or is this a soruce of a memory leak?

I use the construct with the 2 NSString*s throughout my code and if these should be alloced/initted and then released, fine, I just need to know one way or the other. My current understanding is this is the right way to do it, as is coded, but I may be misinformed.

I don't have any explicit retain of MainView anywhere in my code. The object is initialized from Nib, and then added as a subview to my main window. There does not seem to be any problem when I build with SDK 3.0 as the base, but it now actually crashes rather than getting an EXC BADACCESS message. The backtrace now reads:

#0 0x90a1a688 in objc_msgSend ()
#1 0x922bc38a in CFRelease ()
#2 0x31dd1545 in CALayerUpdateSublayers ()
#3 0x31ddf43f in -[CALayer dealloc] ()
#4 0x31e126a7 in CALayerRelease ()
#5 0x31ddaf2b in CALayerFreeTransaction ()
#6 0x31dd260f in CATransactionCommit ()
#7 0x922b8772 in __CFRunLoopDoObservers ()
#8 0x922ba1d4 in CFRunLoopRunSpecific ()
#9 0x922baaa8 in CFRunLoopRunInMode ()
#10 0x31566600 in GSEventRunModal ()
#11 0x315666c5 in GSEventRun ()
#12 0x30a4eca0 in -[UIApplication _run] ()
#13 0x30a5a09c in UIApplicationMain ()
#14 0x00002950 in main (argc=1, argv=0xbfffef08) at /Volumes/Olorin/Projects/Pusher/main.m:14

For this particular crash, I started the app, and immediately selected the "i" to go to the flipside screen. The crash occurs when I select "Done" in the flipsideView. Subsequent tries give minor differences

objc[1210]: FREED(id): message release sent to freed object=0x54ceb0
#0 0x90a0abfa in objcerror ()
#1 0x90a0ac30 in _objcerror ()
#2 0x90a09637 in _freedHandler ()
#3 0x922bc38a in CFRelease ()
#4 0x31dd1545 in CALayerUpdateSublayers ()
#5 0x31ddf43f in -[CALayer dealloc] ()

It is consistent. It crashes in SDK 2.2 and 2.2.1, but runs (apparently) under SDK 2.0, 2.1 and 3.0 just fine, i.e. not crashing, and the modal dialog sets up and releases fine.

Any ideas. I added an explicit retain in both MainViewController and again in AppDelegate just after "creation" and those retains make no difference. My next best guess is it is some other object, not my main window, as first suspected/detected. I also disabled animation of the modal dialog.
So, I'm not really sure what the next thing to try is, except to double check the retain/release on other objects, starting with the flipside view.

I added NSLog messages at all the dealloc routines to see what is being deallocated, and the only output was from Flipside View (not flipsideViewController) and flipsideView doesn't release anything, although it does call

[super dealloc]

Ok, it seems that in FlipsideViewController either one or the other of

- (void)viewDidUnload {
 // Release any retained subviews of the main view.
 self.sceneLabel = nil;
 self.sceneNameLabel = nil;
 ...

or

- (void)dealloc {
 [sceneLabel release];
 [sceneNameLabel release];
 ...

triggers the EXC BADACCESS exception. Not doing one or the other does not crash.

This bothers me, because this appears to be common in all the code examples I've seen. For any field defined as an object pointer, and which has RETAIN in it's property definition, the use of both

 self.sceneLabel = nil;
and
 [sceneLabel release];

is explicitly shown as the proper behavior. This is loaded from a Nib, as in most code examples as well. The ONLY other places in my code which access these locations is also in FlipsideViewController is

- (void)refreshFields {
 NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
 MainViewController* mainViewController = (MainViewController*) delegate;
 MainView* mainView = (MainView*) mainViewController.view;
 sceneLabel.text = mainView.currentSceneKey;
 sceneNameLabel.text = mainView.currentSceneName;
 tileSetLabel.text = [[defaults objectForKey:@"tileSetName"] stringValue];
 soundEffectsSwitch.on = ([[defaults objectForKey:@"soundEnabled"] isEqualToString:@"YES"]) ? YES : NO;
 randomSceneSwitch.on = ([[defaults objectForKey:@"randomEnabled"] isEqualToString:@"YES"]) ? YES : NO;
}

which sets the proper values from the MainView or defaults instances. I did try this with both "field.text =" and "self.field.text" with no discernible difference. And in

- (void)viewWillDisappear:(BOOL)animated {
 NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
 NSString* prefValue = (soundEffectsSwitch.on) ? @"YES" : @"NO";
 [defaults setObject:prefValue forKey:@"soundEnabled"];
 prefValue = (randomSceneSwitch.on) ? @"YES" : @"NO";
 [defaults setObject:prefValue forKey:@"randomEnabled"];
 [super viewWillDisappear:animated];
}

as you can see, there are all read references. Is there a bug in the 2.2.x runtimes since it doesn't crash with 2.1 or 3.0? (I didn't do an extensive trial of all the other SDK versions, since I only want to support the last free version and later).

I don't expect to add many more settings or defaults at this time, and I don't expect the user to constantly be flipping back and forth to change these.

Well, apparently this is proper coding, or at least CLANG thinks so. My first runthrough, clang complained about my extra

[mainView retain];

as a memory leak, and also said to use

 arc4random()
instead of
 random()

and that was it. It apparently liked everything else. Cool. I was belaboring whether I was coding properly or not over nothing.

I still don't like commenting out one or the other of the "self.field=nil" or the "release", but if that stops me from crashing, It will have to do for now. I'd still like to know what might be different in 2.2 that causes the crash, but works fine in other versions.