Change in iOS 14 Beta 3 to trigger 0xdead10cc

FYI, TN2151 has effectively been obsoleted by Diagnosing Issues Using Crash Reports and Device Logs and related articles. Specifically, the official doc for exception codes like this Understanding the Exception Types in a Crash Report.

A problem like this could be a system bug or it could be a benign change in system behaviour that exposes a bug on your side. It’s kinda hard to say with more details. However, IMO it’s always worth filing a bug for stuff like this, in that the system is supposed to be binary compatible from release to release.

Simultaneously, I think it would behoove you to investigate exactly which file is triggering this problem. One trick is to log all the files you have open at the time you become eligible for suspension and then, when you crash, look through that list for likely suspects.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

One trick is to log all the files you have open

The mechanism for doing this is not exactly obvious, so I’ve pasted in a code snippet below.

IMPORTANT This is for debugging purposes only. Using code like this in production raises all sorts of issues, most critically that other threads can be changing the file descriptor table while you’re walking it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

---

Code Block  
func openFilePaths() -> [String] {
		(0..<getdtablesize()).map { fd in
				// Return "" for invalid file descriptors.
				var flags: CInt = 0
				guard fcntl(fd, F_GETFL, &flags) >= 0 else {
						return ""
				}
				// Return "?" for file descriptors not associated with a path, for
				// example, a socket.
				var path = [CChar](repeating: 0, count: Int(MAXPATHLEN))
				guard fcntl(fd, F_GETPATH, &path) >= 0 else {
						return "?"
				}
				return String(cString: path)
		}
}

Thanks Quinn, I stumbled upon some C code for that and was writing it up in Swift too, thanks for saving me the time and helping me debug the cause.

I was able to narrow down the file that is triggering the problem as I was able to reproduce this on my personal device so I could see the relevant Console log regarding suspension and termination:

Code Block json
[application<…>:3879] Terminating with context: <RBSTerminateContext| domain:15 code:0xDEAD10CC explanation:[application<…>:3879] was suspended with locked system files:
/var/mobile/Containers/Shared/AppGroup/A66EB78A-2BBC-49D4-BDEA-6A2AF7E8A5A6/default.realm.lock
not in allowed directories:
/var/mobile/Containers/Data/Application/E1435A44-ABC6-4254-B547-B5423D9FCAB1
/var/mobile/Containers/Data/Application/E1435A44-ABC6-4254-B547-B5423D9FCAB1/tmp reportType:CrashLog maxTerminationResistance:Interactive>

This points to Realm's default.realm.lock being the locked file which is not permitted as it sits within the App Group container as opposed to the app's own container (which I presume is the first 'allowed directory').

Whilst this explains the cause of the crash on beta 3 it doesn't explain why this only started occurring on beta 3.

I will file a bug report as you suggest with respect to binary compatibility but any insights you might be able to provide now we've narrowed down the affected file would be much appreciated too!

I have filed bug report FB8128103. I wasn't 100% on which component to select so chose UIKit, however if this seems better placed set to something else on your side please do tweak/update so it lands with the right team.

This does appear to be a b3-unique thing, and judging by the crash logs I'm seeing on-device, it's affecting system apps like Spotlight and Safari as well. I also am unable to reproduce it at all when building using Xcode 12 to device (only Xcode 11-built binaries seem to reproduce it), but that may be a coincidence.

I have also filed FB8116961 for this one.

In my own experiences with two projects, either building from Xcode 11.6 or Xcode 12 beta 3, the issue of Realm lock file in shared group did exist on real devices. If you use the simulator, everything is fine.

Realm 5.3.2.

There is an issue on realm too. But it seams people believe it is Apple who to blame.

https://github.com/realm/realm-cocoa/issues/6671

Just to add to what's already been said here: This issue is re-producible when running an affected app on an actual iOS device running iOS 14 Beta 3 (not on the simulator), even with the debugger attached, as follows :-

1. Build & Run an affected app on an actual iOS device running iOS 14 Beta 3.

2. Swipe up from the bottom (or press the home button if your device has one) while the app is in the foreground to send it to the background.

That's it: A short moment later, the system kills the app, and Xcode's Console reads:

Code Block 
Message from debugger: Terminated due to signal 9

I have also filed FB8214214 for this issue (and included a quick & dirty sample project).

Just updated to beta 4 and the issue persists.

For those who had filed issues to Apple. Did you get any replies? As this issue still exists in beta 4 now.

Nothing yet for my bug report, still marked as Open.

Is there any updates about this issue? Or any way to walkaround this issue? Apps keep crashing...

iOS 14 beta 4 still happens "Termination Reason: Namespace RUNNINGBOARD, Code 0xdead10cc"

The issue persists in beta 5.

Hey guys, I just reproduce the bug without Realm. It's all about holding flock in App Group directory. You can follow these steps to quickly reproduce the weird crash:

1. Create a new iOS App project (Objective-C) using Xcode.

2. Add an App Group container in project setting page.

3. Paste this code snippet in application:didFinishLaunchingWithOptions::

Code Block objc
    // 1. prepare a non-empty file under App Group directory
    NSFileManager* fileManager = [NSFileManager defaultManager];
    NSURL* dir = [fileManager containerURLForSecurityApplicationGroupIdentifier:@"group.xxx.xxx....."]; <= your group id here
    NSURL* fileUrl = [dir URLByAppendingPathComponent:@"file"];
    [fileManager createFileAtPath:[fileUrl path]
                         contents:[@"some data..." dataUsingEncoding:(NSUTF8StringEncoding)]
                       attributes:nil];
    
    // 2. hold a file lock
    int fd = open([fileUrl path].UTF8String, O_RDWR);
    int ret = flock(fd, LOCK_SH);

4. Debug the project on a physical device running iOS 14 b3/b4/b5.
5. The app will be killed after you return to home screen.
6. If you unlock the file by calling flock(fd, LOCK_UN) before the app enters suspended state, the app won't be killed by iOS.

---

Note that:

• This only crash on a physical device, not a simulator.

• Xcode does not handle it like a normal crash. It just print a termination message in console and ends the debug session gracefully.

If you unlock the file by calling flock(fd, LOCK_UN) before the app
enters suspended state, the app won't be killed by iOS.

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. I took a look at our investigation of this (r. 66931425) but it’s too early for me to post any concrete details. I hope that’ll change soon (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"