Thanks for your messages. Here is a repository that reproduces the crash. Run https://github.com/groue/GRDBIssue1619 in a simulator (Xcode 16 RC) The README of the repository explains different steps for reproducing, or solving the crash, inspired from this post by Mike Ash: https://mastodon.sdf.org/@mikeash/113124733046738455 I also submitted FB15110709 (with my poor understanding of the issue)

Hello, I'm quite confused, actually. People report the crash with Xcode 16 RC when running on iOS 18. Some people report that the crash only happens when the minimum target is set it 18 - but not all. Since it's a crash when opening a Swift existential, I initially suspected a linker error. Hence my mention of GRDBInternal. Later on, another user mentioned https://github.com/swiftlang/swift/issues/75155, which is also a runtime crash when opening an existential. It wasn't a linker error but a compiler bug, in a very specific context: pre-built GRDB & ABI resilience. None of my users have reported that their crash happen in such a specific context - it looks like they are using the regular SPM integration. It's clear I have to come up with a clear repro.

I'm aware of one existing feedback for this issue: FB14907330

I'm afraid it's impossible to guarantee database integrity (I mean foreign keys and other relational invariants) with CloudKit and CKRecord. I recommend reading this article: https://useyourloaf.com/blog/wwdc22-core-data-lab-notes/ It is about Core Data, but many points apply to GRDB just as well. In particular, it contains this interesting sentence: Cloud-enabled stores have a number of restrictions. Relationships are optional. Usually we recommend having another store that is not CloudKit enabled. Copy the data from the CloudKit store to the local store where you can perform validation. Serve clients from the local store where you know the graph is valid.

Adding my voice here as well to report that Xcode 15 makes debugging sessions slow and painful, and that I wish a future release makes the debugging experience good and snappy. On top of that, unplugging the device while a debugging session was on has triggered the nastiest iOS bug I've ever seen (twice): The UI of the debugged app is unresponsive. I can't go back to the Home Screen (the gesture does not work). I can swipe down the notification panel, but can't switch to any other app from there. I can swipe down the control center, but can't switch to any other app from there. I can take a screenshot, but can't switch to any other app from there. The standard shutdown (click buttons on both sides) does not work. Basically I'm completely stuck on a unresponsive app, without any possibility to do switch to any other app. The only solution was the very-little-known reboot gesture (short press on the sound up button, short press on the sound down button, long press on the button on the other side). This means that I had to find a computer until I could google for the solution and bring my phone back to life. And you know how phones are important nowadays. Really not a pleasing experience, Xcode 15 :-/

The issue is solved in beta 2 :-)

> I guess the Core Data team had the same questions for its SQLite store. And since Core Data-powered applications don't have to perform any specific handling in their background callbacks, I think there is still some information to gather.Well... Core Data is not immune against 0xdead10cc: https://blog.iconfactory.com/2019/08/the-curious-case-of-the-core-data-crash/Thanks to all the information gathered in this thread, I think we'll be able to make GRDB better :-)

Thank you very much Kevin! I have no question left, and I can proceed on using all this precious information :-) And kudos for Eskimo if he brought you here ;-)I guess the Core Data team had the same questions for its SQLite store. And since Core Data-powered applications don't have to perform any specific handling in their background callbacks, I think there is still some information to gather. But right now I have one clear path that avoids 0xdead10cc, and that was my main concern.

I'm really afraid it's difficult to understand why there is a problem.I tried to explain again there:> Welcome to the world of modern applications.>> After a background task has expired, the application is not suspended yet. Many things can happen until it gets suspended for good. Core Location can notify a location update. An application timer can fire. A network request can end. All of those events may trigger a database access.>> And if we would start a background task then, we would not be notified of its expiration, because it was started too late. Yes, that means 0xdead10cc.

Thanks for your anwer Eskimo :-) I'm also happy to meet you in your favorite forums!>> Is there one way to be notified of this transition from suspended to background state?> No [...] right now you have to track each resume-in-the-background source independently.Great, that's one less question :-)> I suspect I’m misunderstanding something here but here goes… If you start a UIApplication background task to cover your work, you won’t be suspended until that task either completes or expires. What else do you need?After background task has expired, I need to know 1. when we're back from suspended state (answered in the previous question) and 2. if it is possible, at that moment, to start another background task which will reliably notify its expiration = the beginning of new threat of 0xdead10cc = the beginning of a new lapse of database lock prevention (instead of database lock regrets).The "problem" with both beginBackgroundTask(expirationHandler:)and performExpiringActivity(withReason:using:) is that none of them tell when they are called improperly, when it is no longer time to call them because app has entered its last seconds before being suspended again. In this case, they do not call their expiration handler. There is no API which is able to reliably tell "you're in the danger zone". There are only APIs that reliably tell "you've transitioned from the safe zone to the danger zone". And that's quite different.When there is no API, we call documentation, experience, and knowledgable people to the rescue ;-) My last question: from each of the "resume-in-the-background source", are we sure it is possible to begin a new background task and be notified of its expiration? If the answer is yes, I'm happy. If it is no, then... I'll have to let some 0xdead10cc crashes pass, or spend an insane amount of time testing each one of the "resume-in-the-background source", on various iOS versions, until I can document to the GRDB users when they can "relax" database lock prevention or not (of course, this is a joke, because I can not physically perform those tests).

I forgot the link to TN2151: https://developer.apple.com/library/archive/technotes/tn2151/_index.html