-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock race condition using realm within app group #4797
Comments
Hi @pauluhn. Thanks for reaching out. I wanted to let you know that we've received your report and that someone will review what you've shared and follow-up with you soon. |
I'm able to reproduce this on-device (it works fine in the simulator) and am looking into how to debug it. |
Seems to be caused by realm/realm-core#2402. If I revert that then everything works... until it crashes due to the exact problem that PR was trying to fix. |
Wrapping the write transaction with I think we also have a bug where being suspended at the wrong point in a write transaction breaks things entirely as I've sometimes seen things get in to a state where none of the apps hold the write lock and are all waiting for it, but not allowing suspension during writes is enough to at least dodge that issue. |
Is that bug being tracked? Thanks for the workaround on preventing the issue. And I saw that the docs were updated re: writes being synchronous and blocking. |
Looks like this is exactly an issue being caused in my app. The stack trace I've recovered looks very similar to the reported one, like this (sorry I couldn't symbolicate the Realm.framework itself by mistake):
But the thing is, this is caused between my app and the Today Extension that are using the same app group container, not by an individual applications. What's worse is, it looks like the Today Extension is the process locking up the the Realm database first, since not matter how many times I force-quit the main application the Realm database is still deadlocked, but once I open up the Today Extension UI on my device this deadlock is solved, 100% succeeds. This means the potential fix @tgoyne is pushed in #4827 is completely helpless for this situation, because obviously you can't use I have completely no idea how to fix this in an alternative way... currently I just decided not to use the shared app group container for now, which of course hinders my application's functionality a lot, but there's no choice. |
This is something we're hoping to bring up at Apple's Core OS lab during WWDC next week. |
Please file a radar asking for the ability to perform background tasks from extensions. |
Sure. That sounds like you've spoke with them and had no joy (´・_・`)
|
Here's a copy of my radar in OpenRadar: http://www.openradar.me/radar?id=4931832244076544 I doubt they'll hear this but anyway, we do have to do what we can do. |
My app has just been afflicted with this issue, due to an extension crash or suspension while in a Realm transaction, the main app is permanently deadlocking. If/when you talked to Apple engineers about this issue, was NSFileCoordinator mentioned? https://developer.apple.com/documentation/foundation/nsfilecoordinator Since there isn't a way to perform background tasks in an extension, please consider using NSFileCoordinator, which is the Apple-recommended way to deal with reading/writing files within an app container by multiple processes. Starting a coordinated read or write will ensure that the app and extension are given enough time to complete the file operation, and background tasks shall be started appropriately under the covers, even within an extension. |
Yes, in the sense that they admitted that there's no good official way to do this on Darwin platforms, but that we could misuse NSFileCoordinator to accomplish this. |
I'm not sure if this has been discussed, but Apple put out a tech note regarding 'safe' multi-process file transactions. |
That tech note is somewhat old so some of the information is stale. Apple isn't very good at updating their old tech notes. Since then, iOS 8.2 documentation refers to a way to NSProcessInfo.performExpiringActivityWithReason:usingBlock: to perform longer-running tasks in extensions https://developer.apple.com/documentation/uikit/uiapplication/1623031-beginbackgroundtaskwithexpiratio iOS 8.2 also added NSExtensionHostDidEnterBackgroundNotification Sounds like a good topic to bring up again at WWDC, unless there is a good surprise waiting in iOS 12. |
Yeah I assumed they had things covered since then, but hoped that something might have been related. Fingers crossed for iOS 12 Extension information. |
We are also experiencing app freeze while using callkit and notification extension and accessing realm within there callbacks. Though we have removed realm usage from notification extension, it has solved 95% of freezes. Though it is still needed in the callkit. If the process executing realm transaction aborts, why is realm file, not accessible from main ui thread? |
We are experiencing this issue in Home Assistant now as well. We have quite a few extensions in play, so this isn't just isolated to the Today Extension. |
@manuroe seems like you've found a way to fix it in that other project, could you give advice to the realm core team or to the end users on how to approach this deadlock issue? There are so many critical internal issues in the realm that stay unattended forever that I'm about to port out! |
Unfortunately, I have no fix, just a poor workaround where we avoid to write to the Realm DB from our notification extension. Network data is written to files. Those files will be processed again by the app on its next startup. This implementation works well with this matrix.org project but it cannot be applied everywhere. |
Around 2-3 years back we had the same issue. We followed the same approach that @manuroe mentions. Since that project I have not used realm anymore. |
No description provided.
The text was updated successfully, but these errors were encountered: