Crash Log Help!

Discussion in 'iOS Programming' started by sleaver, Jan 17, 2011.

  1. sleaver macrumors member

    Jul 21, 2010
    Could someone please help me with a crash log? The bug has been winding me up for ages and it's got to the point where I have to admit default and ask for help!

    Would I be right in thinking that it cant find [NewsUnifiedFeedListTableViewController dataSourceDidFinishLoadingNewData]?

    If someone can see more info in the log please let me know as I'm having trouble! Also why would it not be able to find the selector if that is the problem when it works 99% of the other time?

    Plus is it related to:
    NSInvalidArgumentException: -[NSCFString state]: unrecognized selector sent to instance 0x260e50
    Note that the above came from another device just in case the HEX numbers are meaningful. Plus could it be cause by the following line?

    [newsTabBar.button setTitle:@"View Sources" forState:UIControlStateNormal]; 
    If so it doesn't explain the crash log as that still happened with that line commented out!

    Anyway, any help with the crash will be really appreciated.
  2. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    Look at Tech Note 2151 and Tech Note 2123 for info on understanding crash logs.

    Look up NSAssert(), that's what caused your app to "crash."

    The problem happened here:


    and is most likely caused by an under-retain bug.

    You could use NSZombies and Build and Analyze to figure this out.
  3. sleaver thread starter macrumors member

    Jul 21, 2010
    Thanks for the info, line 608 is as follows:

    [refreshHeaderView setState:EGOOPullRefreshNormal];
    I cannot see anywhere where it's released. In the .h file I have:
    EGORefreshTableHeaderView *refreshHeaderView;
    In the .m file:
    if (refreshHeaderView == nil) {
    refreshHeaderView = [[EGORefreshTableHeaderView allocinitWithFrame:CGRectMake(0.0f0.0f self.mainTableView.bounds.size.heightself.mainTableView.bounds.size.widthself.mainTableView.bounds.size.height)];
    refreshHeaderView.backgroundColor = [UIColor colorWithRed:226.0/255.0 green:231.0/255.0 blue:237.0/255.0 alpha:1.0];
    self.mainTableView addSubview:refreshHeaderView];
    self.mainTableView.showsVerticalScrollIndicator YES;
    refreshHeaderView release];
    This may seem trivial to some so I apologise if I'm asking stupid questions! Is it because I do not have a @property line in the .h file for refreshHeaderView?

    How do you know it's NSAssert that caused it?

    Also is there a simple way of getting NS Zombies to work as I have tried in the past and the option in the menu is also grayed out?

    Lastly, I have only ever had this happen on a device and never been able to catch it in debug!
  4. sleaver thread starter macrumors member

    Jul 21, 2010
    Hopefully I have got a bit further with this but it's still crashing!

    I've changed to code of creating the object to the following so I'm not actually releasing it!
    if (_refreshHeaderView == nil) {
    EGORefreshTableHeaderView *view = [[EGORefreshTableHeaderView allocinitWithFrame:CGRectMake(0.0f0.0f self.mainTableView.bounds.size.heightself.view.frame.size.widthself.mainTableView.bounds.size.height)];
    view.delegate self;
    self.mainTableView addSubview:view];
    _refreshHeaderView view;
    view release];
    However I now get the following in the crash log:
    Line 553 is:
    [_refreshHeaderView egoRefreshScrollViewDataSourceDidFinishedLoading:self.mainTableView];
    I've also stopped releasing mainTableView just in case but no luck

    As I've said before it only seems to happen when the app left on a certain tab and changed to this one when the app is re-entered!

    Any help is appreciated!
  5. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    I recommend that you set up a property for that refreshHeaderView and manage it correctly like an outlet. This problem could be due to a memory warning. That view is unloaded but your controller maintains a pointer to it, which becomes stale.

    It's been a while since I used the zombies. Look at the debugging magic tech note TN2124. It's an environment variable and can be turned on in the debugging pref panel for the target.

    The crash in objc_msgSend that you show is also caused by an object being messaged after it was dealloced.
  6. sleaver thread starter macrumors member

    Jul 21, 2010
    When you say a property do you mean @property (nomadic, retail) etc and then synthesis it in the .m file?

    As can be seen in the code I've posted I check to see if the object is nil and re-create it if needed which is done in I think viewWillAppear which via another breakpoint is called every time so I really don't get it!

    I've been putting break points in and when I switch tabs in my UITabViewController the dealloc method isn't called so can objects release themselves? Also if I quit the app on a tab but leave it running in multitasking do objects get released then?
  7. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    Yes, I meant @property. It doesn't have to be nomadic though ;-)

    If you force a memory warning on the Sim does this problem occur shortly after?

    Views don't release themselves but in the case of a memory warning the entire view hierarchy is released by the view controller. I don't know that that's what's happening here but I'm guessing that's it. The view controller itself isn't dealloced, only its views.

    Are you adding a subview to a tableview? That's not a good idea. It's possible that when the table view gets reloadData that it rebuilds itself. I don't really know for sure.

    Some view controllers may unload their views when the app goes into the background, not certain about that.
  8. sleaver, Jan 20, 2011
    Last edited: Jan 20, 2011

    sleaver thread starter macrumors member

    Jul 21, 2010
    Yes, I do get a crash after stimulating a memory warning on this line:
    [_refreshHeaderView egoRefreshScrollViewDidScroll:scrollView];
    If I have NSZombies enabled and I mouse over _refreshHeaderView it says something like NSZombie_xxxxxx but if I have NSZombies disabled it just says out of scope!

    So I'm assuming it is getting released somehow but I assume that could be caused by anything that causes a memory warning in the app or just on that view controller?

    Is there anything else I can look out for or is it down to me to find out whats causing the memoery issue and if so is there an easy way of doing that?

    If it's any help I am using the class from this project for the pull down to refresh:

    EDIT - Just been doing a bit of further testing with this method which calls the above line of code:
     - (void)scrollViewDidScroll:(UIScrollView *)scrollView {    

    _refreshHeaderView egoRefreshScrollViewDidScroll:scrollView]; 
    When using zombies refreshHeaderView shows up as a Zombie but why when I have added a @property?
  9. dejo Moderator


    Staff Member

    Sep 2, 2004
    The Centennial State
    What are you doing to retain _refreshHeaderView? (Something a property can help you with, by the way). :)
  10. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    Memory warnings are a fact of life. While you might try to avoid them by using less memory they can still happen if another app is using a lot of memory. Your goal is to write your code so it works correctly in the case of a memory warning.

    When a memory warning happens, all of the view controllers in the app get the didReceiveMemoryWarning notification. Any view controllers that aren't the frontmost view controller will proceed to unload their view hierarchy. Also, viewDidUnload will be called. You should manage this view like it's an outlet and have a property for it and nil it in viewDidUnload. If you do that then your code shouldn't message the view when it doesn't exist.
  11. sleaver thread starter macrumors member

    Jul 21, 2010
    I've added this in the .h file

    @property (nonatomicretainEGORefreshTableHeaderView *_refreshHeaderView;
    So are you saying I should add

    _refreshHeaderView =nil;
    in viewDidUnload?

    If so, after doing a quick test it was re-created in viewWillAppear and didn't crash! Obviously I will do more testing!

    If anyone can expand it why that seems to work it would be great!
  12. PhoneyDeveloper macrumors 68040


    Sep 2, 2008
    You need to use the property in viewDidUnload.

    The reason it doesn't crash is because after that when your code references the ivar or property its value is nil. No more messages can be sent to the dealloced view.

Share This Page