启用Zombie Objects致内存压力崩溃，求ViewController崩溃排查方案

Hey Mark, sorry to hear you're stuck with this tricky crash—let's break down how to tackle it without getting swamped by memory pressure from full zombie object tracking.

能不能仅针对单个ViewController启用Zombie Objects？ #

Short answer: Apple's built-in NSZombieEnabled is a global setting, so there's no official way to limit it strictly to one ViewController. But there are workarounds to mimic this behavior and cut down memory overhead:

• Dynamic toggle via code: You can switch the zombie environment variable on/off around your ViewController's lifecycle. For example:

  // 在ViewController的viewDidAppear里开启僵尸检测
  - (void)viewDidAppear:(BOOL)animated {
      [super viewDidAppear:animated];
      setenv("NSZombieEnabled", "YES", 1);
  }
  
  // 在ViewController的viewWillDisappear里关闭
  - (void)viewWillDisappear:(BOOL)animated {
      [super viewWillDisappear:animated];
      setenv("NSZombieEnabled", "NO", 1);
  }
  

  Keep in mind this is still a global setting, so it might affect other objects created during this window. But it'll drastically reduce memory usage compared to leaving zombies enabled the entire time.

• Manual tracking for key objects: Instead of relying on the system, you can monitor specific objects tied to your ViewController. For example, override dealloc for critical models/views to log when they're released, then add assertions to check if any code tries to access them afterward. You can also use associated objects to flag deallocated objects and catch invalid accesses.

除Zombie Objects外的排查建议 #

These methods are often more efficient than zombies, especially when memory pressure is an issue:

• Enable Address Sanitizer (ASAN)
  This is my go-to tool for memory issues. It detects wild pointer accesses, out-of-bounds memory reads/writes, and leaks—with way less memory overhead than zombies. To enable it:

  1. Open your scheme settings (Product → Scheme → Edit Scheme)
  2. Go to the Run tab → Diagnostics
  3. Check "Address Sanitizer"
     When your app crashes, ASAN will pinpoint the exact line of code accessing deallocated memory, no guesswork needed.

• Audit your ViewController's lifecycle & memory management

  • Check for retain cycles: Use weak self in blocks that reference your ViewController, and ensure delegates are declared as weak (not strong). Add a log to your ViewController's dealloc method to confirm it's actually being released:

    - (void)dealloc {
        NSLog(@"✅ %@ deallocated", NSStringFromClass([self class]));
    }
    

    If this log never shows up, you've got a retain cycle or an external object holding a strong reference to your VC.
  • Clean up observers & timers: Make sure to remove NSNotificationCenter observers, invalidate NSTimers, and cancel ongoing network requests in dealloc or viewWillDisappear. These are common culprits for keeping VCs alive or causing crashes after release.
  • Check delayed execution: Look for dispatch_after, performSelector:withObject:afterDelay:, or animation completion blocks that might hold a strong reference to your VC and execute after it's been released.

• Use the Memory Graph Debugger
  When you reproduce the transition (level complete → back to menu), pause the app and click the Memory Graph Debugger icon in Xcode's debug bar (looks like three circles connected by lines). This will show you all live objects and their reference chains. Look for your ViewController—if it's still in memory when it shouldn't be, you can trace exactly which object is holding onto it.

• Debug the EXC_BAD_ACCESS crash directly
  If you get the crash without zombies enabled:

  1. Note the memory address mentioned in the crash log.
  2. In Xcode, go to Debug → Debug Workflow → Show Disassembly When Debugging
  3. When the app crashes, the disassembly will show you the exact instruction that caused the bad access. You can map this back to your source code by checking the symbol navigator or using the "Jump to Source" option.

内容的提问来源于stack exchange，提问作者Mark A.