Crash in ios15 EXC_CRASH (SIGKILL)

Yeah, that doesn’t look good. Specifically this:

Kernel Triage:
VM - Compressor failed a blocking pager_get

suggests that something went wrong with the compressed memory subsystem of the kernel’s virtual memory pager. Given that this is on a pre-release OS (iOS 15.0 beta) my advice is that you file it as a bug.

Please post your bug number, just for the record.

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

Thanks Submitting crash report: FB9523755 (Crash in ios15 beta EXC_CRASH (SIGKILL))

Thanks @eskimo

ok I got an additional crash report from the customer with some more insight. The previous crash report is almost identical to the current one (so I will attach the most significant difference ). Its also reproducible on iOS 14.6

Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: application<com.glip.mobile.rc>:2931 exhausted real (wall clock) time allowance of 10.00 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: scene-update | WatchdogVisibility: Background | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 7.820 (user 4.990, system 2.830), 13% CPU", | "Elapsed application CPU time (seconds): 0.091, 0% CPU" | ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread:  0

Now it seems that what cause the crash is some additional work that happens before the work during when the crash was reported. I have read the following apple explanation But I am still not 100% sure, in addition I noticed:

Elapsed application CPU time (seconds): 0.091, 0% CPU - that's look like a plausible time to avoid the crash BUT maybe it doesn't take in to account some additional previous time .

Any insights are welcome

Its also reproducible on iOS 14.6

Well, that’s good news.

I got an additional crash report from the customer with some more insight.

Can you post the full crash report? Use the text attachment feature (click the paperclip icon and then choose Add File) to avoid clogging up the timeline.

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

@eskimo

Sorry I didn't find how to add additional crash log to the initial question so I am adding it here

The long wall clock time and the short CPU time suggests that you spent most of the time blocking. Your crash report isn’t symbolicated so it’s hard to say exactly what’s going on. However, I was able to symbolicate the OS symbols at the top of your main thread:

0   libsystem_kernel.dylib   … __ulock_wait + 8
1   libsystem_platform.dylib … _os_unfair_lock_lock_slow + 196 …
2   libobjc.A.dylib          … objc_sync_enter + 36 …
3   SDK                      … 0x1114ec000 + 306572  

This suggests that your code (frame 3) is using a @synchronized and it can’t get that lock because it’s being held by some other thread. For example, this code creates a similar backtrace:

@interface Test : NSObject
@end

@implementation Test

- (void)test {
    [self performSelectorInBackground:@selector(_backgroundAction) withObject:nil];
    [NSThread sleepForTimeInterval:0.1];
    @synchronized (self) {
        NSLog(@"Hello Cruel World");
    }
}

- (void)_backgroundAction {
    @synchronized (self) {
        pause();
    }
}

@end

As to what’s causing this, it’s hard to say without a properly symbolicated log. To start, you need to work out the identity of frames 9 through 3 on your main thread. However, there are a lot of other threads in this process, many of which are blocked in hard to understand ways.

Do you know if this app is using a third-party crash reporter? Or is your SDK a third-party crash reporter? It’s not uncommon for third-party crash reporters to cause weird hangs like this because… well… frankly… it’s not possible to create a reliable third-party crash reporter on iOS. See Implementing Your Own Crash Reporter for more background on this.

Regardless, the next step here is to symbolicate your frames in this crash report. See Adding Identifiable Symbol Names to a Crash Report for advice on that front.

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

@eskimo

Thanks a lot, indeed the issue was caused by sort of complex dead lock, its almost like u described just in my case the background thread after getting the lock was asking main thread in sync way to execute some logic , mean-while a main thread also asked the same lock, but the background thread never released his lock as main thread was not available to execute his logic

@eskimo Please take a look at my report https://feedbackassistant.apple.com/feedback/9816327

 I got these crash logs from Xcode organizer. All of them have no crash reason and organizer shows NO_CRASH_STACK + 0 for them.