Home/ Questions/Q 7697321
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T21:59:07+00:00

Can’t work this out, [UIViewController hash] is being sent to a view controller which

  • 0

Can’t work this out, [UIViewController hash] is being sent to a view controller which has been rightly deallocated, it was pushed onto a navigation and then subsequently popped, then at some random point later this happens. Looks like the UIViewController class has some kind of static collection of view controllers where a reference to the old controller is still being held despite being deleted. 

 206, stop reason = EXC_BREAKPOINT (code=EXC_I386_BPT, subcode=0x0)
    frame #0: 0x0225cdee CoreFoundation`___forwarding___ + 206
    frame #1: 0x0225ccb2 CoreFoundation`_CF_forwarding_prep_0 + 50
    frame #2: 0x017e1cd1 Foundation`objectHash + 33
    frame #3: 0x017e3444 Foundation`hashProbe + 47
    frame #4: 0x017f5d03 Foundation`-[NSConcreteHashTable hashGrow] + 217
    frame #5: 0x017e3407 Foundation`-[NSConcreteHashTable addObject:] + 136
    frame #6: 0x00f98089 UIKit`+[UIViewController setViewController:forView:] + 101
    frame #7: 0x00f94c71 UIKit`-[UIViewController setView:] + 542
    frame #8: 0x017ecf30 Foundation`_NSSetUsingKeyValueSetter + 77
    frame #9: 0x017ecedb Foundation`-[NSObject(NSKeyValueCoding) setValue:forKey:] + 287
    frame #10: 0x01807d50 Foundation`-[NSObject(NSKeyValueCoding) setValue:forKeyPath:] + 393
    frame #11: 0x010ef71a UIKit`-[UIRuntimeOutletConnection connect] + 106
    frame #12: 0x022f7dea CoreFoundation`-[NSObject performSelector:] + 58
    frame #13: 0x022617f1 CoreFoundation`-[NSArray makeObjectsPerformSelector:] + 273
    frame #14: 0x010ee26e UIKit`-[UINib instantiateWithOwner:options:] + 1178
    frame #15: 0x00f941fc UIKit`-[UIViewController _loadViewFromNibNamed:bundle:] + 286
    frame #16: 0x00f94779 UIKit`-[UIViewController loadView] + 302

It looks like the private method [UIViewController setViewController:forView:], called from [UIViewController setView:] stores every view controller in a class level dictionary of view -> view controller perhaps. And at some point later whilst adding another VC to the collection, it needs to grow, this causes all the values to be rehashed in the collection, causing the [UIViewController hash] call to the delloced VC. Now question is why is the VC ref still in there? Maybe its because the view is still alive somehow without it’s controller delegate.

UPDATE: I can confirm that the view controller’s view is still alive after the VC has been popped despite the VC being destroyed. Not quite sure why though.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Wow, well found out what is was, something very bad (slaps own wrist).

    I had refactored an abstract UIViewController subclass into a category on UIViewController, doing something similar to UINavigationController where it adds navigation related functionality to UIViewController. But what I failed to notice was that my UIViewController subclass had implemented dealloc, so once this was converted to a category it replaced UIViewController’s dealloc method.

    You think the complier would give me a warning for that, it usually does if you replace an method with category but doesn’t seem to in the case of dealloc (possibly something to do with ARCs code generation)

    • 0