Changes in v5.3.6 seem to cause app or whole system freeze when foregrounding on iOS 10, 11, 12

[SquaredTiki]

It appears that the changes in v5.3.6 (#6722) to work around the iOS 14 issue of apps using Realm terminating in the background due to file locking (#6671) have created an issue that results in the app or the whole of iOS potentially freezing when an app using Realm is moved from the background into the foreground on iOS 10, 11 or 12.

Downgrading from v5.3.6 to v5.3.5 resolves this issue. You can see this was briefly mentioned in a comment by @thodang888 in #6722 .

Goals

Have my app, which uses a shared app group container, not freeze or cause iOS itself to freeze when it is moved from the background into the foreground.

Expected Results

As above.

Actual Results

After a few times of backgrounding and foregrounding the app, be it via springboard or via a deeplink, the whole device freezes. At this point the device is not responsive to any touch input or pressing the home button (on devices with it). After approx. 30-60 seconds springboard is restarted by Watchdog and the device unfreezes.

Steps for others to Reproduce

Build and run the sample project referenced below or your own project that makes use of Realm in a shared app group container (unsure as of yet if this is a requirement to experience this issue) on a device running iOS 10, 11 or 12 and background and foreground your app repeatedly (leaving a couple seconds in between to ensure the app is truly backgrounded).

Code Sample

I believe it should be reproducible using the code sample from #6671 but on iOS 10, 11 or 12.

Version of Realm and Tooling

Realm framework version: 5.3.6

Realm Object Server version: N/A

Xcode version: 11.3.1 & 12

iOS/OSX version: iOS 10, 11, 12

Dependency manager + version: ?

[bguidolim]

As it was fixed by Apple on iOS 14 b7, I would suggest reverting the commit about new file lock emulation.

[finnschiermer]

Sounds reasonable. @tgoyne agree?

[SquaredTiki]

From what I've heard on the grapevine from folks at Apple, the change in beta 7 and onwards that fixed the iOS 14 issue is a temporary workaround and not meant to be a permanent fix. And that the reason it (i.e. default.realm.lock being ignored by iOS when it performs checks for locked files on app background) worked OK for so long up until iOS 14 was a bug, not a feature.

Might be worth bearing in mind if it's decided to revert the changes in Realm.

[bguidolim]

@SquaredTiki if there is an allow list, this probably includes *.realm.lock, because I don't use the default one and it works fine for me since b7.
Is there any way to confirm this behavior? I didn't see any mention in all beta release notes about it, so I supposed to be an iOS 14 issue.

[SquaredTiki]

@bguidolim From what I've heard previous to beta 3 the lock file was being mistaken for a different type of file and thus being ignored when iOS performed its checks on locked files when the app was backgrounded, this got fixed in beta 3 but caused #6671 and so to maintain binary compatibility Apple added a temporary workaround in beta 7 to continue to permit this incorrect behaviour. Though this is all unmentioned in release notes.

The dev forums post does suggest that Apple engineers see Realm's original behaviour (pre v5.3.6) as incorrect though:

Right, this is expected. Holdling file locks while your app is suspended is exactly what triggers the 0xdead10cc termination. You must release file locks before coming eligible for suspension.

The issue here is that previously working code is now being hit by this check.

[tgoyne]

I can reproduce this. It might be an option to only use the flock workaround on iOS 14+, but before resorting to that I'd like to figure out what exactly is causing problems.

[tgoyne]

The silliest workaround:

var files = [FileHandle]()
let enumerator = fm.enumerator(at: fm.containerURL(forSecurityApplicationGroupIdentifier: "group.io.realm.test")!, includingPropertiesForKeys: [.isDirectoryKey])
for url in enumerator! {
    guard let url = url as? URL else { continue }
    if (try! url.resourceValues(forKeys: [.isDirectoryKey])).isDirectory! { continue }
    (try? FileHandle(forReadingFrom: url)).map { files.append($0) }
}

I don't have a jailbroken device lying around to debug what's actually going wrong (since it's not the app itself hanging), but it appears to be due to having a writer on a named pipe but not a reader. My completely unsubstantiated guess is that it's related to file protection since the kernel checks each fd to see if it needs to be reenabled when the app enters the foreground.

[kunalsood]

the change in beta 7 and onwards that fixed the iOS 14 issue is a temporary workaround and not meant to be a permanent fix

to maintain binary compatibility Apple added a temporary workaround in beta 7 to continue to permit this incorrect behaviour

@SquaredTiki The words "temporary workaround" do not give me a whole lot of confidence, and, implies that Apple will break binary compatibility again. If so, then why would they even bother with a temporary workaround?

Sorry for the off-topic comment.

[SquaredTiki]

@tgoyne That's interesting. I wonder, if you have time of course, if you're able to distill the issue into a simple sample project it'd be worth filing a bug report with Apple for this. Arguably even if Realm was doing something not quite right with named pipes it shouldn't be able to cause the springboard to freeze and restart affecting the whole system.

@kunalsood Good question. My hunch is that the workaround might be removed in a later release of iOS, maybe a minor version change after the initial launch of iOS 14 (as the initial launch is when people are most likely to blame Apple/iOS).

[tgoyne]

Apple generally only releases updates for old versions of iOS for critical security issues and it's already fixed in the latest released version, so it's unlikely that Apple would backport whatever change fixed it.

[SquaredTiki]

That's a good point, slipped my mind that this was already fixed in iOS 13+!

[SquaredTiki]

@tgoyne Is the plan still to implement a workaround for iOS 10, 11, 12 or only use the new changes on iOS 14?

[tgoyne]

realm/realm-core#3907 fixes this and should be pulled into a release soon.