EXC_CRASH (SIGKILL) no termination reason or code iOS 15 - 16

I also created a Report using the Feedback assistant: 11983595

You have a third-party crash reporter in play here (see frames 3 through 2 of thread 2) so there’s no guarantee that this Apple crash report is an accurate representation of your crash. For more background on why that is, see Implementing Your Own Crash Reporter.

Assuming it is, consider the backtrace of your crashing thread:

Thread 0 Crashed:
0  libsystem_kernel.dylib … __terminate_with_payload + 8
1  libsystem_kernel.dylib … abort_with_payload_wrapper_internal + 132 (terminate_with_reason.c:106)
2  libsystem_kernel.dylib … abort_with_reason + 28 (terminate_with_reason.c:116)
3  libobjc.A.dylib        … _objc_fatalv(unsigned long long, unsigned long long, char const*, char*) + 112 (objc-errors.mm:202)
4  libobjc.A.dylib        … _objc_fatal(char const*, ...) + 28 (objc-errors.mm:218)
5  libobjc.A.dylib        … weak_register_no_lock + 332 (objc-weak.mm:422)
6  libobjc.A.dylib        … objc_initWeak + 324 (NSObject.mm:363)
7  libswiftCore.dylib     … swift_unknownObjectWeakInit + 56 (WeakReference.h:270)
8  NYP                    … closure #1 in static FrameConfiguration.nypAdFrameConfiguration.getter + 584 (TileConfiguration+Custom.swift:310)
9  NYP                    … ContainerCollectionViewController.configureCell(cell:indexPath:) + 340 (ContainerCollectionViewController.swift:382)
10 NYP                    … closure #1 in ContainerCollectionViewController.reconfigureVisibleCells() + 20 (ContainerCollectionViewController.swift:290)
11 NYP                    … specialized Sequence.forEach(_:) + 20 (:0)
12 NYP                    … ContainerCollectionViewController.reconfigureVisibleCells() + 20 (ContainerCollectionViewController.swift:288)
13 NYP                    … specialized ContainerCollectionViewController.onEvent(_:from:) + 1872 (ContainerCollectionViewController.swift:444)
14 NYP                    … 0x1044b4000 + 8894752
15 NYP                    … thunk for @escaping @callee_guaranteed () -> () + 28 (:0)
16 Foundation             … __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16 (NSOperation.m:1545)

Frame 16 is Foundation’s NSBlockOperation infrastructure calling out to your code. Frames 15 through 8 are your code. Frame 7 is the Swift runtime which then immediately turns around and calls the Objective-C runtime in frames 6. Frame 5 detects a problem and starts the process of crashing your app. Frames 4 through 0 are artefacts of that process.

If this crash were happening locally you’d get a nice error message. Sadly, the crash reporter won’t capture that for you. However, you can look up the origin of the crash and infer things from there. Specifically, frame 5 references line 422 of objc-weak.mm. You can see that in Darwin [1].

_objc_fatal("Cannot form weak reference to instance (%p) of "
            "class %s. It is possible that this object was "
            "over-released, or is in the process of deallocation.",
            (void*)referent, object_getClassName((id)referent));

This suggests you’re hitting a memory management error. Notably, frame 8 references line 310 of TileConfiguration+Custom.swift, which gives you starting point. What is that code doing with weak references?

Finally, in situations like this I always recommend that you test your app extensively with the standard memory debugging tools. These will often allow you to reproduce a hard-to-reproduce problem like this one.

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

[1] This is the Darwin source that corresponds to macOS 12.5, which is a close match to the source used to build iOS 15.6.1 mentioned in your crash report.