I have an UIButton, which logs the content that is present in a couple of UITextField's.But when I click on this UIButton thrice, the simulator hangs and the debugger is opened. Can someone tell me why is this happening. It happens only when there is content in UITextFields.
Without seeing your code it's hard to diagnose, but it sorta sounds like you are releasing something you shouldn't be. The first two times the object is still valid, but the third time might make an object's retain count zero, and therefore prematurely deallocate it. Check the IBAction method for your UIButton and make sure you aren't releasing things that you haven't explicitly allocated.
Related
I am getting a strange crash due to NSLocalizedString. -[CFString retain]: message sent to deallocated instance 0x3c6ad0.
I am sure it's due to the NSLocalizedString as when I replace it with static string. everything goes fine. Here is the line where I got the error.
[_backButton setTitle:NSLocalizedString(sBackButtonDefaultTitle, nil) forState:UIControlStateNormal];
The sBackButtonDefaultTitle is "Back".
What makes it random is that it crashes sometimes and sometimes not.
EDIT:
The sBackButtonDefaultTitle is defined in a header file
#define sBackButtonDefaultTitle #"Back"
The header is, of course, imported into the .m file.
EDIT:
More details...this back button title is used application-wide. In almost every controller. However, the crash only happens AFTER pushing certain controller.
This controller contains a web view. If I tap the Back button, the controller is poped. No crash. But If I push any controller with the same "Back" button, the application crashing, giving the error I illustrated above.
It's really mysterious. I hope someone can help me fix it.
Surely because you're sBackButtonDefaultTitle has been deallocated when you call NSLocalizedString.
I guess it's an auto-released string.
You may want to check with NSZombie enabled, to be sure.
You may need to retain the sBackButtonDefaultTitle string, when you create it, and release it after the NSLocalizedString call.
This crash is due to sBackButtonDefaultTitle getting released before that point in your code. Check to make sure you are retaining it when you take possession of it and that you are releasing it after using it in that line of code.
A good reason of using NSLocalizedString is to support more than one languages for your app. NSLocalizedString usually goes well with string resource file so that the system can dynamically decide with language it should use to populate your UI. I never tried to use the NSLocalizedString as the way you do, but I can tell you use a string resource file will definitely work. Take a look at Apple's Guidelines for Internationalization
and string resource file
Hope it helps.
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.
I'm creating an iPad game that has a viewController that loads in its view from a nib file. The view has a bunch of buttons in it, which I linked up to UIButton * variables via interface builder (so each button is linked to a different variable). I checked the retain count right after they nib was loaded on one of the buttons (using my first button variable, b1) and it gives me a value of 2. Can anyone explain why it's 2? What are the two things that are retaining it right after the nib loads?
And now I'm even more confused because in my dealloc function, I released each of the button variables individually, and checked the retain count for one of them after and it's STILL 2! It should at least have gone down to 1, shouldn't it have? Should I release it several times in my dealloc function? If so, how many?
Thanks
Don't look at retain count.
Seriously.
Things other than you retain your stuff. Those numbers will move around underneath you for reasons that appear to make no sense, and then you'll come back here and post bewildered questions.
Just make sure your retains and releases balance. That's your only job.
If your IBOutlet properties are retained then you would have 1 retain there and another when the button gets added to the super view...
As Dan Ray says though, you shouldn't really worry about the retainCount...
I just added a UIDatePicker to my iPad app using IB, linked it to its outlet in the code, saved it in IB, added the UIPickerViewDelegate to my UIViewController in the code, as well as added the UIDatePicker outlet in code. When I build and run, the app launches, but will crash intermittently when I attempt to open the popover view that contains the datepicker. I say intermittently because the popover view will occasionally open successfully, but never more than once (it always crashes the second time you open the popover, if it doesn't crash the first time). Also, in the console, I get the following messsage
objc[594]: FREED(id): message lastClickRow sent to freed object=0x6015a70
Why is this happening and how can I fix it?
What does that console message indicate?
It may be worth mentioning that the popover view also contains a table view along with the datepicker control.
Thanks so much in advance for your help!
I too had a tough time getting through this problem but at last got it resolved.
Instead of adding UIDatePicker in interface builder, add it dynamically or programatically. It surely worked for me and hope that it works for you too.
UIDatePicker *_datePicker=[[UIDatePicker alloc] initWithFrame:frame];
[self.view addSubview:_datePicker];
This is almost certainly a reference count issue. It seems odd that your view controller (which I'm assuming is the delegate of your UIDatePicker, since that's where you implemented the protocol) would be released during normal operations, but that's the first thing you should look at - that the delegate is set and remains a valid object at the time you display the popup view.
One funny thing you could have done is to release it UIPopOverController reference after passing it the [presentPopover...] message, just like we do at passing a presentModalViewController message to the UIViewController.
I faced this problem too, one thing you can do is something like
self.funnyPopoverController = aPopoverController;
(of course funnyPopoverController is retain type property here).
Otherwise its hard to predict whats happening without staring at the code for some long long time_t hours :)
Example: I have an warning triangle icon, which is a UIImageView subclass. That warning is blended in with an animation, pulses for 3 seconds and then fades out.
it always has a parent view!
it's always only used this way: alloc, init, add as subview, kick off animation, when done:remove from superview.
So I want this:
[WarningIcon warningAtPosition:CGPointMake(50.0f, 100.0f) parentView:self];
BANG!
That's it. Call and forget.
The view adds itself as subview to the parent, then does it's animations. And when done, it cuts itself off from the branch with [self removeFromSupeview];. And to make sure the procedure can finish really after this, make a nifty -retain and -autorelease couple so the whole thing can complete and return before it really gets trashed.
Now some nerd a year ago told me: "Never cut yourself off from your own branch". In other words: A view should never ever remove itself from superview if it's no more referenced anywhere.
I want to get it, really. WHY? Think about this: The hard way, I would do actually the exact same thing. Create an instance and hang me in as delegate, kick off the animation, and when the warning icon is done animating, it calls me back "hey man i'm done, get rid of me!" - so my delegate method is called with an pointer to that instance, and I do the exact same thing: [thatWarningIcon removeFromSuperview]; - BANG.
Now I'd really love to know why this sucks. Life would be so easy.
I have no objections to your solution—especially with the [[self retain] autorelease]. I'm using the same approach from time to time myself.
You should go and ask the no-branch-cutter-nerd about his reasoning (and post this information here).