调用NSFetchedResultsController.performFetch()时CFString野指针崩溃求助

问题场景 #

调用NSFetchedResultsController的performFetch方法时触发可复现崩溃，代码如下：

NSFetchedResultsController *aFetchedResultsController =
    [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest
                                        managedObjectContext:self.managedObjectContext
                                          sectionNameKeyPath:sectionnamekeypath
                                                   cacheName:cacheName];

aFetchedResultsController.delegate = self;

NSError *error = nil;
if (NO == [aFetchedResultsController performFetch:&error]) {
    NSLog(@"Unresolved error %@, %@", error, [error userInfo]);
}

崩溃发生在performFetch()调用处，Zombie检测输出：

*** -[CFString isNSString__]: message sent to deallocated instance 0x12c6071d0

已排查函数内所有字符串的有效性，未发现对应地址的异常字符串；仅登录数据量达数千条的特定用户时触发崩溃，其他用户数据正常。

定位与解决思路 #

1. 排查Core Data存储的异常字符串 #

由于仅特定用户数据触发，优先怀疑服务器导入的数据存在问题：

• 导出该用户的Core Data SQLite文件，用SQLite浏览器查看对应实体的所有字符串字段，检查是否存在空值、特殊编码字符串或长度异常的内容。
• 修改Core Data实体的字符串属性为copy修饰（在.xcdatamodeld中设置属性的“Storage”为Copy），确保字符串被正确持有，避免导入时出现内存管理问题。
• 临时将cacheName设为nil关闭FRC缓存，缓存可能存储了旧的、已释放的字符串引用，大数据量场景下更容易触发这类问题。

2. 启用Core Data调试参数 #

在Xcode Scheme的“Arguments Passed On Launch”中添加以下参数，获取更多调试信息：

• -com.apple.CoreData.SQLDebug 1：打印FRC执行的SQL查询语句，定位performFetch时访问的具体字段。
• -com.apple.CoreData.ConcurrencyDebug 1：检测多线程访问Core Data的违规操作，避免导入数据时上下文线程冲突导致对象异常释放。

3. 用Instruments深入追踪僵尸对象 #

仅靠控制台的地址输出不足以定位来源，使用Instruments的Zombie模板运行App：

• 触发崩溃后，在Instruments中查看僵尸对象的调用栈历史，可以看到该CFString的创建、释放路径，以及最后发送消息的具体位置。
• 开启“Record Reference Counts”选项，追踪该字符串的引用计数变化，找出异常释放的触发点。

4. 检查sectionNameKeyPath相关逻辑 #

FRC分组时会高频访问sectionNameKeyPath对应的属性，若该属性存在异常则容易触发崩溃：

• 临时将sectionNameKeyPath设为nil，若崩溃消失，则说明分组字段的字符串存在问题，重点排查该字段的导入逻辑和存储状态。
• 确保实体中该字段的getter方法为Core Data自动生成，无自定义释放逻辑或异步操作。

5. 排查ARC下的隐式内存问题 #

即使开启ARC，仍可能出现对象提前释放的情况：

• 检查FRC是否被强引用（比如用@property (strong, nonatomic)持有），避免局部创建后被ARC自动释放。
• 排查导入数据后是否有对上下文的异常操作（如reset、批量删除后未更新FRC），导致FRC引用了已被上下文释放的对象。

内容的提问来源于stack exchange，提问作者Kenny Wyland