I am getting crazy:
*** -[UIAnimator removeAnimationsForTarget:]: message sent to deallocated instance 0x5ba13d0
It happens in different moments, when I scroll my tableview, when I switch my filter (a UISegmentedControl).
How can I fix it?
I just solved the same problem.
I thought it was related to UIAnimation, but it was related to UITableViewCell, instead.
I found a good starting point looking at this article.
http://marius.me.uk/blog/2011/mar/fixing-uianimator-removeanimationsfortarget-crash/
Good luck and let me know!
I had the same symptom (crash caused by [UIAnimator removeAnimationsForTarget:] message being sent to deallocated UITableViewCell, but it turned out to have been caused by a reason different from the one cited in the above solution. It turned out that the reason was that my UI was being updated by a non-UI thread. Specifically, I was calling popViewController:animated: from a background thread. When I moved this invocation to the UI thread via a callback the problem went away.
Both #er0 and #notme's answers are right.
When I made two different Cell UI in storyBoard and tried to use them in tableView:cellForRowAtIndexPath it gave me this error on a completely different button action. That method is not related to UITableViewCell in any way (AFAIK).
First I used #er0's way: on the method I was getting the crash, performed it in main thread.
performSelectorOnMainThread:withObject:waitUntilDone
It solved the crash.
Then I came to realize my tableView:cellForRowAtIndexPath code needs to be refactored. In some special situation I was using dequeueReusableCellWithIdentifier two times for a single indexPath. Refactored the code and placed the if-else in a way that dequeueReusableCellWithIdentifier is not called twice for a single indexPath. It solved my crash and I don't need the performSelectorOnMainThread" any more.
I ended up using notme's solution.
Related
I'm writing a navigation app for iPhone at the moment and I'm having a very weird crash issue and was wondering if anyone had come across (and solved) this issue.
I have two views, both of which contain UITableViews and one that uses cells loaded from a nib. When I push and pop from one view to the other, after a couple of presses (usually 7 to 10) with everything loading and displaying as it should the app suddenly crashes. The debugger shows that CALayer was the last thing running, but I don't use any custom implementation of this class.
My first thought is that I've over-released an object, but after two days of playing with the code I can't identify any zombies.
Does anyone know what's going on here? Can post parts of code if required.
UPDATE:
Looks like zombies are being created on UIView delegate methods, namely viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear. Will investigate further tomorrow. :D
What you can do is to set breakpoints at the dealloc methods of the related classes, and see if the crash happens in one of the method. And also usually by looking at the callstack when the crash is happening, you can tell whether it's a memory related crash or not.
Is there any other reason (than calling "reloadData") why numberOfSectionsInTableView is called twice? I did debugging and found, that it's get called twice during initial startup when no custom reloadData statements are called.
I have created the table with IB but does that might cause a problem?
Have a look at the call stack. you can see that this method is being called from two different scenarios.
Probably your tableView object may instantiate twice. Once i have encountered the same problem due to this.
I'm coding a library (Obj-C for iPhone) that I want to package and sell, so I obviously need to work out any design kinks before listing it for sale. I am also utilizing this library to help me develop another app.
My library is heavily built on task delegation. The primary function I have is to launch a (potentially) long-running process, and when it's done, I call a Delegate Protocol method in the class's delegate.
An additional complicating factor here is that I will often schedule this task to fire off every 30 seconds or so. Usually, I do this with [self performSelector:#selector(someMethod:) withObject:nil afterDelay:30] rather than using an NSTimer. Then, when the delegate method successfully returns, I process the returned data and trigger the method to fire in another 30 seconds. This gives me 30 seconds BETWEEN method calls, rather than 30 seconds FROM THE START OF ONE CALL TO THE NEXT. (This is mainly just in case the call ever takes more than 30 seconds, which shouldn't happen.)
The error that I'm catching is that sometimes, the Delegate callback method is failing with an EXC_BAD_ACCESS error. Based upon my investigation, it appears that the delegate of my class library has disappeared (been released/dealloced) since the long-running process was initiated. Thus, when it calls [[self Delegate] doSomeDelegateMethod], it's accessing a released object.
I tried first checking [[self Delegate] respondsToSelector:#selector(doSomeDelegateMethod)], but even that access apparently also throws the EXC_BAD_ACCESS.
It doesn't yet seem that checking for [self Delegate] == nil is the right way to go, either.
One way I think I have solved the problem, in this specific instance, is when the view controller that instantiates my object is disappearing (and therefore on its way to the garbage dump), I call [NSObject cancelPreviousPerformRequestsWithTarget:self]. This apparently fixes the problem. (Does this "fix" also indicate that my object "knows" about the call to come and keeps itself in memory until it can successfully, desperately, fire off its final shot?)
This appears to put a band-aid on a bullet wound. Yes, it appears to stop my app from breaking this time, but my gut tells me that this is a poor solution.
I've also considered setting the custom object to nil in my viewWillDisappear:animated: method, which is probably the correct coding pattern, but it doesn't seem right that the customer has to be so precise in handling my objects.
What's really bugging me, though, is that I haven't yet found a way, as a library developer, to "box in" my code so that it won't throw an exception for the user if they don't do just the right things. Basically, I'd like a way to have my object:
Get a request.
Go look for the answer.
Find the answer.
Try to return the answer.
Realize that there's nothing on the other end.
Give up and die on its own. (OK, so "die on its own" probably won't happen, but you get the point.)
One interesting side point:
A main reason I have for preventing this type of error from occurring is this:
I did the following steps:
Built my library's .h/.m files.
Generated my library's .a output file.
Imported my library's .a/.h files into another project.
Had the error described above.
Got to peruse the code from one of the .m files that SHOULD have been hidden inside the .a file.
Am I missing something here? Am I really risking exposing my entire source code if it ever throws an error for a client? (This is just a side issue, but I'm fairly concerned here!)
Thanks for any help you can provide to help me be a better programmer!
---EDIT---
I have found another reason why this is important. In another view controller, where I am using this library, I implemented the NSTimer strategy. If the view is popped from the navigation stack (i.e., in the viewWillDisappear:animated: method), I invalidate said timer. So, no more calls will go to my library after the view disappears.
Here's the rub: what if the view disappears IN THE MIDDLE of the long-running call? Yes, it's tricky and unlikely to do, but I just had it happen on the simulator. In particular, THIS is why I'm looking for a workaround to let my code realize "hey, there's nothing on the other end of this pipe" and then fail gracefully. Anyone?
Thanks!
There are several approaches to this problem:
The traditional delegate approach (UITableViewDelegate) makes it a requirement to clear yourself as delegate before going away. This is traditionally done in dealloc of the delegate with otherObject.delegate = nil. Failure to do so is a programming error. That's basically what you're seeing. This is the common pattern when the delegate and the delegator have basically the same lifespan.
Another approach is how NSURLConnection handles it: retain your delegate until you're done. The key to this working well is that NSURLConnection has a lifespan of its own, so the retain loop will work itself out automatically. UITableView could not retain its delegate because this would almost always create a permanent retain loop. If your object lives for a while and then goes away, then this makes sense. Typically here the delegate has a much shorter lifespan than the delegator, so the retain loop doesn't hurt anything.
Any object that calls performSelector:withObject:afterDelay: should always call cancelPreviousPerformRequestsWithTarget:self in its own dealloc. This has nothing to do with your delegate, though. It should be self-contained to the object itself. (I don't know why I keep thinking this is true, and then proving to myself again that it isn't. When you call performSelector:...afterDelay:, you are retained, so you can't deallocate before it fires. My SIDE NOTE, while true, isn't relevant here.)
SIDE NOTE cancelPrevious... is really expensive in my experience. If you have to call cancelPrvious... very often, I recommend keeping your own one-shot NSTimer and just resetting it when it fires to get the same effect. performSelector:withObject:afterDelay: is just a wrapper around a one-shot timer.
I'm answering myself because the page warned me to not have extended discussions in the comments... :)
OK, so it appears that part of my answer is that [self performSelector:withObject:afterDelay:] automatically retains my object until it gets to "fire that shot", at which point I'm guessing the view controller dies.
So, now it makes sense why my custom class is trying to access a released object when it tries to return its answer to its delegate, which is an __unsafe_unretained object, meaning that it can die at will (I think).
What I'd like now is a way to prevent this from causing an error. In .NET, I've got all sorts of error handling options to do this, but I'm unable to think of a fail-safe "bail out" here.
I've tried [[self Delegate] isKindOfClass:..., but can't be sure what kind of class the delegate will be, so it won't work.
I've also tried [[self Delegate] respondsToSelector:#selector(...)]. I'm not sure why this fails, but I get the EXC_BAD_ACCESS here, too.
What I don't want is my customers to be able to crash my product with such a simple, innocent mistake.
As an aside, does anyone know why this sort of failure gives me such easy access to the contents of the .m file that should be hidden inside my .a file? Did I build my library incorrectly?
Thanks!
Try setting Delegates to nil in dealloc.
example:
self.fetchedResultsController.delegate = nil;
I've seen this problem a lot lately and usually fix the problem. Even though delegates are supposed to be weak references, sometimes some private implementation is using them as well.
If I release, I get bad access, if I retain, I leak
That's where I had a similar problem.
Edit: When using ARC, you can still override dealloc for cleanup, you just can't call [super dealloc] or release anything.
I have a problem I can't locate clearly, maybe you can help me...
I have an iPad project, based on UINavigationController, most (but not all) of controllers inside are instances of UITableViewController, and everything works well...
Everything excepting that my application crashes randomly, sometimes after 10 minutes of use, sometimes after only 10 seconds...
It never crashes on the same view, never at the same time, making that difficult to reproduce.
In addition, it only seams to happen on device, I've never got this crash in the simulator.
The debugger doesn't help me very much, here is what it says:
-[UITableView autorelease]: message sent to deallocated instance 0x8e9800
And here is the call stack:
http://i.stack.imgur.com/JSCHx.png
Any idea ?
Thanks (and sorry for my english)
You're overreleasing a UITableView somewhere in your code. Are you calling release or autorelease on the UITableView inside one of your UITableViewControllers? You should only release objects that you 'own'. You get to own an object by using methods beginning with alloc, new, copy, or retain.
Please read the cocoa memory management guidelines for more info.
Useful links:
http://www.cocoadev.com/index.pl?MemoryManagement
http://www.cocoadev.com/index.pl?RulesOfThumb
At some point you are either releasing a UITableView instance that you do not own or you are failing to retain one at some point where you keep a reference to it (e.g. you store it in an ivar or a property declared assign rather than retain).
I have written about how to debug things like this on my blog:
http://loufranco.com/blog/files/Understanding-EXC_BAD_ACCESS.html
Basically, try these three things first:
Do a Build an Analyze and fix everything you see
Turn on Zombies, run your code -- it will tell you if you talk to dealloced objects
If that fails, try Debug Malloc, but that's way harder.
I apologize, after re-reading all my source code, I found ONE ViewController (I have around 20 ViewController), where I released an Outlet, in ViewDidUnload.
The reason that it crashed randomly is that I didn't understood well the mechanism of ViewDidUnload, it is called to release views (but not objects of controllers) when memory is low and view is not visible (ex: First ViewController of a NavigationController), and the views are re-loaded when the ViewController become visible again...
In simulator, memory is rarely an issue so ViewDidUnload is almost never called...
Problem fixed, thank you everyone for your help
To help with making sense of the trace, see iOS Debugging Magic (Technical Note TN2239) and Understanding and Analyzing iPhone OS Application Crash Reports (Technical Note TN2151).
Jeff
I have the following code in a view controller that (in all other respects) seems to be working fine:
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
ProblemViewController *problemViewController = [[ProblemViewController alloc] initWithNibName:#"ProblemViewController" bundle:nil];
problemViewController.problem = (Problem*)[self.problems objectAtIndex:indexPath.row];
[self.navigationController pushViewController:problemViewController];
[problemViewController release];
}
When I run through this function, however, I am getting the following error:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[ProblemViewController initWithNibName:bundle:]: unrecognized selector sent to instance 0x57ca80'
I'm at a loss as to what could be causing it, so my question is: How should I best go about debugging this problem? Is there anything obvious I should be checking?
Check the base class for ProblemViewController. I'm betting you're not inheriting from UIViewController, which includes the initWithNibName:bundle: method.
There are a bunch of answers to this question that all basically say the same, correct, thing: Somehow, the method you're trying to call doesn't actually exist.
BUT, if you're beating your head against the wall (like I was for an hour today), make sure you try cleaning your project in xcode first. Sometimes, I don't know why, xcode can get into a bad state and will not properly compile your project into the simulator. It will tell you the build is successful, but when deployed to the simulator, you start seeing runtime errors as though only half your changes were picked up. So yeah, that happens.
You likely don't have that method implemented in your ProblemViewController. Unrecognized selector is, as far as I know, just that there's no method defined in this class's interface that has that signature.
Try declaring it in your interface like this:
- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil;
I thought I better post something on this issue. I fought it for a couple of days. There are a lot of blogs on this, but none of them solved the problem. Some suggested that it had to do with pushViewController needing to specify animated:YES. It worked for some, but that didn't work for the issue I was having. I was using a button to access another view rather than selecting a row from a table view, but was getting the same unrecognized selector error. I was also using a navigation controller so I thought it had something to do with that, but it didn't. Finally, I decided to comment out lines of code till the message went away. After commenting out the method that was causing the problem, the error message still came up in the console. That is when I realized the problem was not with my source code. One site recommended performing a clean and rebuild. I tried all that and still the problem persisted. I then looked at my XIB file using Interface Builder to see what methods(Received Actions) displayed on the File Owner. There was the problem. Not only did the offending method show up once on the File Owner, but it displayed twice. Don't know how to display the image of this here. Anyway, I deleted the methods (Received Actions) with the same name that appeared on the File Owner. I performed a clean and rebuild to see if the error went away and it did. I then uncommented the source I thought was bad and built the project again and the call to the new view was successful.
I will share my experience with the same error code. It is possible to make a mistake my assigning a the object to the wrong target. For example, if you have some UILabel property and you have accidentally assigned the string constant directly to self.myUILabelProperty = #"ups" then you property will become object of type NSString instead of being UILabel, so you loose all the UILabel methods. After that mistake, if you try to use UIlabel methods on the property in code you will get this error message.