iOS应用在main.m崩溃（无日志/断点无效）求助

Let’s tackle this head-on—EXC_BAD_ACCESS (code=1) is almost always a memory-related issue (like accessing an object that’s already been deallocated or hitting an invalid memory address). While your constraint conflict might not be the direct culprit, it’s smart to rule it out first since wonky layout can sometimes trigger unexpected memory behavior.

First: Resolve the Constraint Conflict (Even If It Seems Unrelated) #

Your constraint conflict is clear—the cell’s height is fixed at 56.5, but your vertical constraints add up to far more than that:

• SafeArea top (0) + 7 + Label1 height (40) + 2 spacing + Label2 height +13 + SafeArea bottom (0) = at least 62, which is way over the cell’s 56.5 height. The system breaks Label1’s height constraint to recover, but this "band-aid" can lead to view hierarchy chaos or indirect memory issues.

Here’s how to fix it:

• Adjust the fixed height constraint: Change Label1’s height == 40 to height <= 40 (so it can shrink to fit the cell) or remove it entirely and let auto-layout calculate the height based on content.
• Fix the cell’s height: If the cell is supposed to be taller, update the UIView-Encapsulated-Layout-Height constraint (this usually comes from the table view’s estimated row height or static row height). Use UITableView.automaticDimension if you want dynamic cell heights.
• Get better constraint debug info: Re-set your UIViewAlertForUnsatisfiableConstraints symbolic breakpoint correctly:
  1. Go to the Breakpoint Navigator (cmd+8)
  2. Click the + button → Symbolic Breakpoint
  3. Enter UIViewAlertForUnsatisfiableConstraints as the symbol
  4. Under "Actions", add a Debugger Command and input:

     po [$arg1 constraintsAffectingLayoutForAxis:UILayoutConstraintAxisVertical]
     

  5. Check "Automatically continue after evaluating actions"
     This will print a detailed list of conflicting constraints when the issue hits, making it easier to pinpoint which ones to adjust.

Next: Track Down the EXC_BAD_ACCESS Crash #

Since exception breakpoints aren’t helping, let’s use Xcode’s most powerful memory tools:

1. Use the Zombies Instrument #

This is the gold standard for finding over-released objects:

• Go to Xcode → Product → Profile (cmd+I)
• Select the "Zombies" template and click "Choose"
• Run your app until it crashes. The Zombies instrument will show you exactly which object was accessed after being deallocated, along with the stack trace of where it was released and where it was accessed again.

2. Enable Address Sanitizer #

This tool catches memory errors in real time:

• Go to Xcode → Edit Scheme (cmd+<) → Run → Diagnostics
• Check "Address Sanitizer"
• Run your app again. When it crashes, Address Sanitizer will give you a precise line of code or framework method that caused the invalid memory access, along with a detailed explanation.

3. Dig Into the Crash Call Stack #

When the app crashes at main.m, don’t stop there—look up the call stack in the Debug Navigator (cmd+7):

• Expand Thread 1’s stack frames. The crash happens in main, but the real issue is likely in a frame above it (look for your app’s classes/methods, or system methods that relate to your code).
• If the stack is mostly assembly, enable "Show Disassembly When Debugging" in Xcode → Preferences → Debugging. Then, in the debugger console, run:

  image lookup --address 0x760b9beb8
  

  This will tell you which library or method that memory address belongs to, giving you a clue where to look.

4. Check Recent Code Changes #

Ask yourself:

• Did this crash start happening after adding/modifying constraints?
• Have you worked with any manual memory management (if using MRC), blocks, or weak/strong references lately?
• Did you add any code that modifies collection objects (arrays, dictionaries) or views that might be deallocated prematurely?

Try commenting out sections of code related to the CourseSectionCell or the view controller with constraints, then run the app again. If the crash goes away, you’ve narrowed down the scope.

Final Note #

It’s possible the constraint conflict and crash are unrelated, but fixing the constraint issue first eliminates one variable. The memory tools (Zombies, Address Sanitizer) are your best bet here—they’ll cut through the lack of logs and show you exactly what’s going wrong.

内容的提问来源于stack exchange，提问作者Felipe Borges