i am getting an NSInvalidArgumentException with reason: -[UITapGestureRecognizer initWithCoder:]: unrecognized selector sent to instance
my understanding was that UITapGestureRecognizers were supported in ios4.x?
is it possible to load a different xib file for sub ios5 versions?
As #mit3z states in his comment on the original question, iOS 4.3 supports this feature only when setup up manually with code. It is not supported with Interface Builder.
Apple would have saved us all grief over this if they simply added this as a build-time warning.
I think you have a NSCoding compliant object that is deallocated before the crash. The UITapGestureRecognizer is allocated at its address and when the disappeared object (but not its reference) tries to call initWithCoder on itself, it actually calls this method on your gestureRecognizer instead.
Then your problem comes from that deallocated object but not from your gestureRecognizer.
Be sure to retain all your IBOutlet properties.
Related
I have a document based cocoa app where each document is a web view.
Sometime when I close a document it crashes. Running Zombies it says An Objective-C message was sent to a deallocated 'MyDocument' object (zombie) when the crash happens.
It says the responsible caller is -[NSDocumentController makeUntitledDocumentOfType:error:].
I don't understand why this method would be getting called after I close a document.
I finally found the solution after some help using a technical support incident with Apple.
I had to nil out the ui delegate in my -dealloc. Everything works fine now.
- (void)dealloc
{
[self.webView setUIDelegate:nil];
}
The engineer told me for compatibility reasons even when using ARC most objects still have to use __unsafe_unretained references for their delegates instead of __weak.
I am working on an iPad application which is converted to ARC. Application is for os >= ios 5.0. So my doubt is that, how do I manage viewOutlets? I use -(void)didReceivememoryWarning to set ViewOutlets to nil. But in ios 5.0 and 5.1 application shows lots of memory leaks. As -(void)viewDidUnload is deprecated in ios 6.0 , I am not using the same in the application. Is the correct way to manage outlets? Please give me a quick reply.
ARC (automatic reference counting) features is available in iOS 5 and ahead (iOS 6 and so on..) version.
When you are using ARC unable in your project, you dont need to `manually release any object` that you have allocated for your stuff.
ARC will automatic handle this one.so it will beneficial for `Memory Management`.
Hope ,You understand what i m trying to say.
for more clarification , please refer below link:
To ARC or not to ARC? What are the pros and cons?
ARC, worth it or not?
Good Luck !!!
There is NO DIFFERENCE in how you code for iOS 5 vs. iOS 6.
If you are having problems, it's because you don't understand what viewDidUnload does and when it's called.
viewDidUnload is called when the view of the controller is unloaded. In iOS 6, views are never unloaded. In iOS 5 and before, views were almost never unloaded either. So in both cases, pretty much viewDidUnload is never called.
If your program is leaking stuff, it's because you are not releasing things. You always need to release instance variables in dealloc. I suspect that this is your problem.
When the controller's view is unloaded (which only happens in iOS 5 and before, but this is irrelevant), viewDidUnload allows you to optionally discard some resources to save memory, as long as they are resources that will be re-created when the view is loaded again. This usually includes properties and instance variables that are outlets (since when the view is loaded, it will load the Xib again and re-connect the outlets to new objects), as well as any variables that are set in viewDidLoad.
If you coded your program correctly, I can go in there and remove viewDidUnload, and it would not have any effect on the correctness of the program. (Since viewDidUnload is almost never called anyway.)
You should almost never have to use didReceiveMemoryWarning either.
I'm playing around with Julius Guzy's sample code for creating a document based application that can save text files. I ran his code and it works perfectly and the app runs/save files (All in the latest version of Xcode. Though Guzy's sample code compiles using the 10.6 SDK). I'm trying to learn from it and rewrite the code. I have everything in order to compile the app but for the strangest thing in MyDocument.m. I am unable to run it.
#synthesize nsTextViewObj;
Xcode is giving me this error, which I don't really understand it.
Existing ivar 'nsTextViewObj' for property 'nsTextViewObj' with
assign attribute must be __unsafe_unretained
nsTextViewObj; is suppose to be linked to the "File Owners" in IB. I did that in the first place. It beats me why I'm getting that error. SDK conflicts maybe? How can I fix this?
ARC requires some changes to the code. Xcode provides a tool to automatically convert non-ARC code to ARC: Edit / Refactor / Convert to Objective-C ARC…
The Xcode tool is a good start, still I would recommend you to read Transitioning to ARC Release Notes.
I don't know Julius Guzy's code, but probably you should change it to something like:
#interface ifc_name : NSWindowController {
NSTextView *__unsafe_unretained nsTextViewObject;
}
#property (unsafe_unretained) NSTextView *nsTextViewObject;
As the name implies, unsafe_unretained is not safe: when the object is deallocated, your reference is invalid. If you are deploying only to iOS 5 or higher, and OS-X 10.7 or higher, you can use weak instead. With weak your reference will become zero when the object is deallocated.
I am having an interesting memory management problem with an iOS app.
I have a property which when release using [self.propertyName release]; will cause the property to be released twice and cause a bad memory access exception on an iPad 1/iOS 4 device (in the dealloc of the property).
When the this code is changed to [_propertyName release]; (accessing the local variable instead of the property), this will cause a leak on an iPad 3/iOS 5.
Of course, I can stop this from happening by checking the OS version, but I would like to understand what I am doing wrong.
Some more details:
The property is a subclass of UIViewController, as is the object who owns the property. I am adding the property's UIView as a subview. I have heard this is not good practice, but we are doing it elsewhere without the memory problems.
The test cases are:
iPad 1, iOS 4.2 - Needs to release using the ivar [_propertyName release]
iPad 2, iOS 5.0 - Needs to release using the property [self.propertyName release]
iPad 3, iOS 5.1 - Needs to release using the property [self.propertyName release]
Adding another viewController's view as a subview is bound to cause strange issues, when you release the other viewController it's view will still be retained by your main view but it's viewController will have disappeared.
That said self.propertyName = nil is the best way to release properties, just make sure you have removed the subview from your main view first.
I converted my app to ARC and noticed that an object alloc'ed in one of my view controllers was not being dealloc'ed when that view controller was dealloc'ed. It took a while to figure out why. I have Enable Zombie Objects on for my project while debugging and this turned out to be the cause. Consider the following app logic:
1) Users invokes action in RootViewController that causes a SecondaryViewController to be created and presented via presentModalViewController:animated.
2) SecondaryViewController contains an ActionsController that is an NSObject subclass.
3) ActionsController observes a notification via NSNotificationCenter when it is initialized and stops observing when it is dealloc'ed.
4) User dismisses SecondaryViewController to return to RootViewController.
With Enable Zombie Objects turned off, the above works fine, all objects are deallocated. With Enable Zombie Objects on ActionsController is not deallocated even though SecondaryViewController is deallocated.
This caused problems in my app b/c NSNotificationCenter continues to send notifications to ActionsController and the resulting handlers cause the app to crash.
I created a simple app illustrating this at https://github.com/xjones/XJARCTestApp. Look at the console log with Enable Zombie Objects on/off to verify this.
QUESTION(S)
Is this correct behavior of Enable Zombie Objects?
How should I implement this type of logic to eliminate the issue. I would like to continue using Enable Zombie Objects.
EDIT #1: per Kevin's suggestion I've submitted this to Apple and openradar at http://openradar.appspot.com/10537635.
EDIT #2: clarification on a good answer
First, I'm an experienced iOS developer and I fully understand ARC, zombie objects, etc. If I'm missing something, of course, I appreciate any illumination.
Second, it is true that a workaround for this specific crash is to remove actionsController as an observer when secondaryViewController is deallocated. I have also found that if I explicitly set actionsController = nil when secondaryViewController is dealloc'ed it will be dealloc'ed. Both of these are not great workaround b/c they effectively require you to use ARC but code as if you are not using ARC (e.g. nil iVars explicitly in dealloc). A specific solution also doesn't help identify when this would be an issue in other controllers so developers know deterministically when/how to workaround this issue.
A good answer would explain how to deterministically know that you need to do something special wrt an object when using ARC + NSZombieEnabled so it would solve this specific example and also apply generally to a project as a whole w/o leaving the potential for other similar problems.
It is entirely possible that a good answer doesn't exist as this may be a bug in XCode.
thanks all!
Turns out, I've written some serious nonsense
If zombies worked like I originally wrote, turning on zombies would directly lead to innumerable false positives...
There is some isa-swizzling going on, probably in _objc_rootRelease, so any override of dealloc should still be called with zombies enabled. The only thing that won't happen with zombies is the actual call to object_dispose — at least not by default.
What's funny is that, if you do a little logging, you will actually see that even with ARC enabled, your implementation of dealloc will call through to it's superclass's implementation.
I was actually assuming to not see this at all: since ARC generates these funky .cxx_destruct methods to dispose of any __strong ivars of a class, I was expecting to see this method call dealloc — if it's implemented.
Apparently, setting NSZombieEnabled to YES causes .cxx_destruct to not be called at all — at least that's what happened when I've edited your sample project:
zombies off leads to backtrace and both deallocs, while zombies on yields no backtrace and only one dealloc.
If you're interested, the additional logging is contained in a fork of the sample project — works by just running: there are two shared schemes for zombies on/off.
Original (nonsensical) answer:
This is not a bug, but a feature.
And it has nothing to do with ARC.
NSZombieEnabled basically swizzles dealloc for an implementation which, in turn, isa-swizzles that object's type to _NSZombie — a dummy class that blows up, as soon as you send any message to it. This is expected behavior and — if I'm not entirely mistaken — documented.
This is a bug that has been acknowledged by Apple in Technical Q&A QA1758.
You can workaround on iOS 5 and OS X 10.7 by compiling this code into your app:
#import <objc/runtime.h>
#implementation NSObject (ARCZombie)
+ (void) load
{
const char *NSZombieEnabled = getenv("NSZombieEnabled");
if (NSZombieEnabled && tolower(NSZombieEnabled[0]) == 'y')
{
Method dealloc = class_getInstanceMethod(self, #selector(dealloc));
Method arczombie_dealloc = class_getInstanceMethod(self, #selector(arczombie_dealloc));
method_exchangeImplementations(dealloc, arczombie_dealloc);
}
}
- (void) arczombie_dealloc
{
Class aliveClass = object_getClass(self);
[self arczombie_dealloc];
Class zombieClass = object_getClass(self);
object_setClass(self, aliveClass);
objc_destructInstance(self);
object_setClass(self, zombieClass);
}
#end
You will find more information about this workaround in my blog post Debugging with ARC and Zombies enabled.
Turns out it is an iOS bug. Apple has contacted me and indicated they've fixed this in iOS 6.
to answer the second question you would need to remove the observer from NSNotification - that will keep it from calling the view.
Normally, you would do this in the dealloc but with that zombie issue maybe it's not getting called. Maybe you could put that logic in viewDidUnload?
Because you have open NSZombieEnabled, this let the object not call dealloc, and put the object to a special place. you can close NSZombieEnabled and have try again. And double check if your code have circle retain condition.