-[Not a Type Retain]: Message Sent to Deallocated Instance

-[Not A Type retain]: message sent to deallocated instance

This bridged cast may not work, as hatfinch describes in his answer here, because the CGColorRef returned from -CGColor may not hang around after your last reference to the UIColor that generates it. I thought this was a bug, based on the discussion in this Apple developer forum thread, but it was a misreading of how to manage the lifetime of these CGColorRefs.

One way that this will work is to use the built-in bridging provided by the -CGColor method on UIColor. Rather than saving out your CGColor to a temporary variable as you do above, you should be able to use something like the following:

NSArray *colors = [NSArray arrayWithObjects:(id)[color1 CGColor],
                                            (id)[color2 CGColor], nil];

with color1 and color2 being UIColor instances.

The bridging is taken care of for you by the -CGColor method, according to the "The Compiler Handles CF Objects Returned From Cocoa Methods" section of the Transitioning to ARC Release Notes. The documentation is currently missing the cast to id that I have above, which is required to get this to compile.

I've tested this, and it seems to work in my case, matching what Ben reports in the above-linked Developer Forums thread.

In addition to the above, you can explicitly retain and release the CGColorRefs returned from the -CGColor method and bridge them across in your NSArray, again as hatfinch shows here.

CGImageRelease: [Not A Type release]: message sent to deallocated instance

Even worse than what someone0 is telling you:

I would say as you defined your uiImageToSave in the else block, the reference you created with imageToSave is not valid outside of the else block - so any use of imageToSave in your code is just working by accident, as long as the memory is not overwritten yet.

And as said, the [UIImage CGImage] call only gives you a reference to the image data, it does not make a copy or retain it - so you may not release it yourself, it is released automatically when the UIImage ceases to exist - which in your case is just one line after you make the reference.

UPDATE:

The code in the original posting is adjusted - the uiImageToSave is now defined in the right place (just if anyone wonders about my comment which is now not really fitting the original posting anymore :-).

[UINavigationController retain]: message sent to deallocated instance

Finally after days of investigations I've found a reason to all these crashes including the one described in "iOS memory warning sent to deallocated UIViewController"

The problem came out from PHAirViewController project. I still did not find out a real reason, but simply commenting out - (void)dealloc function in PHAirViewController.m file did the magic.

The main headache I got when was running Instruments to detect NSZombies. All traces were pointing to system classes like UINavigationController, UIImagePickerViewController etc... Due to this I started disabling ARC for parent controllers. In some places it helped but in some it didn't.

After a lot of voodoo I found out that every class (including system classes) was implementing UIViewCOntroller(PHAirViewController) Category and though - (void)dealloc function was always called on dismissing them.

Now the only thing left is to understand why this function is generating NSZombies. The interesting thing is that just commenting its content (which have only one line: self.phSwipeHandler = nil) does not have the same effect.

[UITextField retain]: message sent to deallocated instance

This issue happens because you have call to dismissViewControllerAnimated. Due to VC life cycle all objects, that this VC holds will be deallocated. That means, that all manipulations with UI after dismiss are not memory-safe.

From the documentation:

This method looks at the current view and its subview hierarchy for
the text field that is currently the first responder. If it finds one,
it asks that text field to resign as first responder. If the force
parameter is set to true, the text field is never even asked; it is
forced to resign.

So, your VC had been deallocated while endEditing was looking thorough hierarchy, as I guess. It's the only one reason, that may cause memory problem.

Why do you need call to endEditing before dismissing? simply dismiss VC without this call. if you have logic, that depends on endEditing - separate it and call instead of endEditing. Hope this helps.

UPDATE:

Try to call endEditing in viewWillDisappear - this triggers view to resign first responder right before it will be dismissed.

retain viewcontroller - message sent to deallocated instance

I had not set the root view controller like so:

    self.window.rootViewController = rootController;

---

Related Topics