EXC_CRASH from NSManagedObjectContext executeFetchRequest

Question

alexcason OP

Created 1d

Replies 2

Boosts 0

Participants 3

Hello,

I have an iOS app for which I've received a number of similar crash reports over the last few months. Despite a lot of effort, I haven't been able to replicate the crash myself and I'm finding it difficult to diagnose.

The main view of the app loads a list of items from Core Data using @FetchRequest and looking at the logs it appears to me that this is the most likely source of the crash as the call stack includes SwiftUI 0x19c78c368 FetchRequest.update() + 472 (FetchRequest.swift:406). It also appears as if this happens on launch as the crash times and launch times are always very similar.

I've attempted lots of things to try and replicate the crash, such as launching the app a lot of times, creating lots of items so that the fetch request has a lot of data to retrieve, performing any other database related actions in the app immediately after launch to try and drive out any concurrency issues and simulating degraded thermal and network conditions for the device.

I've included a sample crash report, I'd be very grateful if anyone has any suggestions for diagnosing the issue.

Crash Report

Boost

Answer 1

deeje OP

5h

are you doing anything with core data in background threads?

0

Answer 2

DTS Engineer OP

Apple

2h

The main view of the app loads a list of items from Core Data using @FetchRequest and looking at the logs it appears to me that this is the most likely source of the crash as the call stack includes SwiftUI 0x19c78c368 FetchRequest.update() + 472 (FetchRequest.swift:406). It also appears as if this happens on launch as the crash times and launch times are always very similar.

This is just guesswork, but I do have two ideas.

A) Did you see and follow this warning:

"Always declare properties that have a fetch request wrapper as private. This lets the compiler help you avoid accidentally setting the property from the memberwise initializer of the enclosing view."

The documentation doesn't say this explicitly, but I think what they're warning about there is that it's posible to end up in a situation where the process of updating your interface based on a fetch request can end up accidentally modifying that data it's trying to display, which basically ends up rentering CoreData. I think this still trigger a crash in the same way calling "performBlockAndWait" inside a "performBlockAndWait" call would.

B) On the reproduction side, this is worth thinking about more:

"It also appears as if this happens on launch as the crash times and launch times are always very similar."

The work you're doing isn't what I'd associate with a "basic" app launch, so I suspect that this might be tied to some form of state restoration. Testing wise, I'd focus on putting your app into interesting/unusual state, not just "brute force" testing. Also, under "Settings.app-> Developer", there is a switch labeled "State Restoration Testing-> Fast App Termination" which could be very helpful here. Turning that on means that system will terminate your app whenever it suspends, forcing your app to restore state every time it comes to the foreground. That will let you test this code path while avoiding the disruption force quitting could cause.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0