0

I receive the following error while my UITableView is loading: 

*** -[NSObject respondsToSelector:]: message sent to deallocated instance 0x23fa7cff0

I've used NSZombies to track down the error to the line:

SHFeedCell *cell = (SHFeedCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];

Where CellIdentifier has previously been declared:

CellIdentifier = [SHFeedCell getCellIdentifierForPost:currentPost];

I've included an image from instruments. Any help is greatly appreciated!

enter image description here

Log output: 

2015-01-09 12:34:49.896 Shout[73650:6147424] -[SHFeedTableViewController tableView:cellForRowAtIndexPath:] line 478 $ cell identifier: feedCellImageDescription
2015-01-09 12:34:49.974 Shout[73650:6147424] -[SHFeedTableViewController tableView:cellForRowAtIndexPath:] line 481 $ cell: <SHFeedCell: 0x25150bc40; baseClass = UITableViewCell; frame = (0 0; 320 495); autoresize = RM+BM; layer = <CALayer: 0x25151bfe0>>
2015-01-09 12:34:50.051 Shout[73650:6147424] *** -[NSObject respondsToSelector:]: message sent to deallocated instance 0x2514edff0
cph2117
  • 2,651
  • 1
  • 28
  • 41
  • `[static NSString *CellIdentifier = [retrieve CellIdentifier dynamically` That is not code so what the heck is it? – matt Jan 09 '15 at 17:24
  • And what on earth is the purpose of the image from Instruments? No one cares how much _time_ this takes; you need to be tracking down retains/releases. – matt Jan 09 '15 at 17:25
  • Added more useful image and code – cph2117 Jan 09 '15 at 17:28
  • Prove, please, that the code `CellIdentifier = [SHFeedCell getCellIdentifierForPost:currentPost];` has actually run and provided a non-nil result _before_ the `dequeueReusableCellWithIdentifier` call. – matt Jan 09 '15 at 17:31
  • Added log output showing that both cell identifier and cell are not nil – cph2117 Jan 09 '15 at 17:35
  • Are you sure this has anything to do with `dequeueReusableCellWithIdentifier`? I am a bit confused by that. The zombie problem is on a `respondsToSelector` call. – matt Jan 09 '15 at 17:43
  • Per the first image I posted, NSZombie seems to have picked out 'dequeueReusableCellWithIdentifier' as the problem line, but if you have any other ideas regarding where the 'respondsToSelector' issue is, I'd be happy to explore them. Is there anyway I can get the object from the memory address? – cph2117 Jan 09 '15 at 17:50
  • I don't know what you mean by "the first image". I now see just one image, and it focuses on your scroll view delegate. You don't show enough of the stack trace for me to see what's going on, but maybe you can figure it out from there. – matt Jan 09 '15 at 17:53
  • Is that not UITableview's internal scrollview? – cph2117 Jan 09 '15 at 17:55
  • Okay, good theory. But a zombie means that something has vanished behind the code's back, and now the code is trying to send a message to that vanished thing. What has vanished? Is it the table view's delegate? – matt Jan 09 '15 at 17:58
  • Okay, so I found what's being deallocated, but I don't understand why...In `SHFeedCell`, I have a `scrollView` that's connected through `IBOutlet`. Unfortunately, when `-(void)awakeFromNib` is called, the `scrollView` is `null`, which is odd seeing as it was defined in a `Nib`. It's not deallocated immediately, but only after a couple of iterations. Any thoughts? – cph2117 Jan 09 '15 at 20:59
  • Wow, you've made huge progress on this! - Can you say more about how the nib loads, how it is set up, how the scroll view is configured? And does it have a delegate? (I'm still wondering if it is the delegate, not the scroll view, that is missing in action.) – matt Jan 09 '15 at 21:51
  • As of now, I think I solved it. the `self.scrollView.delegate = self` had been set in an `SHFeedCell` method as opposed to `SHFeedCell`'s `awakeFromNib` method. – cph2117 Jan 09 '15 at 21:55
  • Excellent! Well done. – matt Jan 09 '15 at 22:29

0 Answers0