views:

152

answers:

2

I have an iPhone SDK application that has several views that appear and disappear as the user creates content. After using the application on a device for a while, I get the following crash:

Program received signal:  “EXC_BAD_ACCESS”.
(gdb) backtrace
#0  0x33369ebc in objc_msgSend ()
#1  0x320e5248 in -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded] ()
#2  0x338b4a14 in -[NSObject performSelector:withObject:] ()
#3  0x320e5098 in -[UIAnimator stopAnimation:] ()
#4  0x320e4b7c in -[UIAnimator(Static) _advance:] ()
#5  0x320e4a34 in LCDHeartbeatCallback ()
#6  0x34350e60 in HeartbeatVBLCallback ()
#7  0x332e91c0 in IOMobileFramebufferNotifyFunc ()
#8  0x316532f8 in ?? ()
#9  0x33866b50 in __CFMachPortPerform ()
#10 0x338ae52a in CFRunLoopRunSpecific ()
#11 0x338adc1e in CFRunLoopRunInMode ()
#12 0x3434e1c8 in GSEventRunModal ()
#13 0x32002c30 in -[UIApplication _run] ()
#14 0x32001230 in UIApplicationMain ()
#15 0x00002ff8 in main (argc=1, argv=0x2ffff550) at /Developer/svn/MyCompany/iPhone/MyApplication/Other Sources/main.m:14

As you can see from the trace, the only mention of my code in there is the call to main.

I have run Build and Analyze from Xcode, and also set it up to run the clang analyzer on my project from the Terminal, and both of these cannot find any problems in the code. I am using a very recent release version of the iOS SDK (I have not downloaded the 4.1 yet, but the one I am using is the one that was in release right before 4.1).

Also, I have run the application in Instruments with the Simulator, and the app has no memory leaks.

I am about to try to use the NSZombieEnabled variable and see if that finds anything, but the problem is that I need to use the application for 30 to 40 minutes or so before it crashes, and I suspect that NSZombieEnabled may not even help me find the issue.

It seems like the crashes that I have seen is when a modal view calls a delegate in the parent view controller. The parent view controller then does some processing before dismissing the modal view controller. There is some references in the crash to animating and scroll views, but I am not sure what I could be doing to cause those to have problems. Does anyone have any suggestions for things to look for?

EDIT: I have put the NSZombieEnabled flag into the application, and on the device, it comes up with this message in the console:

2010-09-11 17:10:33.970 MyApplication[9321:207] *** 
-[MyViewController respondsToSelector:]: message 
sent to deallocated instance 0x7489480

As far as I can tell, I am setting the delegates used in the application to nil in the deallocs of all my classes, so I am stuck as to where to look next.

I tried to use the malloc_history pid address command on this, but it said that it could not find the process, I tried 9321, 9321:207, and 207. Also, if I try to use the MallocStackLogging variable, the program will not run on the device, I get a bunch of malloc: unable to create stack log directory messages in the console and a program crash.

Oh, and by the way, I can't use the zombies checking in Instruments, since it does not appear to work with a device, and I can't get the same crash to happen in the Simulator.

A: 

My guess would be that the scrollview's delegate is set to an object that has been deallocated. Try settings all the delegates of child objects to nil in your dealloc methods.

rpetrich
+2  A: 

The UIScrollView on stack frame #1 probably wants to inform its delegate about the animation ending, but the delegate is gone at that point. Setting NSZombieEnabled would probably confirm this.

Delegates are not retained, so this is a common error in Cocoa and Cocoa Touch. Look for delegates on UIScrollView or UITableView in your code and try to find out which one might be released before its time.

Nikolai Ruhe
+1. To be explicit, delegate properties should always be set to `assign` and not `retain`
Shaggy Frog
There's always an exception to the rule. See `NSURLConnection` for a valid reason to retain a delegate.
Nikolai Ruhe
I do have a UITableView that resides on a UIViewController, and when the app crashes, I believe that it is getting ready to go back to this view controller. However, the delegate for this UITableView is set in Interface Builder, and it is not changed anywhere in the code.
BP
This delegate might be the problem. To verify, use `NSZombiesEnabled`. You have to take care that the delegate lives longer than the UITableView (or the property on the table view is set to nil). Of course, IB is not to blame because it does not handle lifetime. You have to do this in your application logic.
Nikolai Ruhe