What does Arg[0] = Dead in a UICollectionViewDataSource crash mean?

Detailed explanation here:

https://stackoverflow.com/questions/30764669/whats-dead-exploded-in-swifts-exception-stack

Dead: The argument is unused in the function body and can be removed in a dead argument elimination pass.

Could you show the code ? In particular, didSelectItemAt

But why would a Dead argument cause a crash?

The didSelectItemAt would look like this:

class CollectionViewDataSource: NSObject, UICollectionViewDelegate, UICollectionViewDataSource {
    var sectionAHandler: (() -> Void)?
    var sectionBandler: ((URL) -> Void)?

    …

    public func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
        guard let section = Section(rawValue: indexPath.section),
              let item = self.item
        else { return }

        switch section {
        case .sectionA:
            sectionAHandler?()
        case .sectionB:
            if case .someEnum(let url) = item.urlKind {
                sectionBHandler?(url)
            }
        }
    }
    
    …
}

I try to resolve an enum defining the available sections, check if some item is available and if that is case, I switch on the section enum and call some function if available.

It should not be the cause of crash.

Just check by using collectionView, for instance

    public func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
       print(collectionView.frame, collectionView.numberOfSections)

And see it it still crashes.

Is it the real code ? Seems to be a typo:

    var sectionBandler: ((URL) -> Void)?

Should be

    var sectionBHandler: ((URL) -> Void)?

Yes, that was of course a typo. However, I cannot reproduce that error! The app and my code is running fine. The error is only visible in the crash reporting. But it's rare, really rare. I'm talking about 0.01 % of all app sessions. But I would like to understand and perhaps even avoid the crash.

But it's rare, really rare. I'm talking about 0.01 % of all app sessions. So that could mean the objects gets deallocated, by system at the time of use.

Did you get a full crash log ?

Yes, I have the full crash log at hand. The crashed thread looks like this:

Exception Type:  SIGTRAP
Exception Codes: TRAP_BRKPT at 0x102f59f38
Crashed Thread:  0

Thread 0 Crashed:
0   MyApp                                0x0000000102f59f38 function signature specialization <Arg[0] = Dead> of MyApp.MyDataSource.collectionView(_: __C.UICollectionView, didSelectItemAt: Foundation.IndexPath) -> () (<compiler-generated>:0)
1   MyApp                                0x0000000102f59258 @objc MyApp.MyDataSource.collectionView(_: __C.UICollectionView, didSelectItemAt: Foundation.IndexPath) -> () (<compiler-generated>:0)
2   UIKitCore                            0x0000000183ab06e8 -[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:performCustomSelectionAction:] + 896
3   UIKitCore                            0x0000000183e4a300 -[UICollectionView touchesEnded:withEvent:] + 612
4   UIKitCore                            0x00000001839940f8 forwardTouchMethod + 340
5   UIKitCore                            0x00000001839940f8 forwardTouchMethod + 340
6   UIKitCore                            0x00000001839940f8 forwardTouchMethod + 340
7   UIKitCore                            0x0000000183903574 _UIGestureEnvironmentUpdate + 6704
8   UIKitCore                            0x00000001839360b0 -[UIGestureEnvironment _updateForEvent:window:] + 780
9   UIKitCore                            0x0000000183943250 -[UIWindow sendEvent:] + 4424
10  UIKitCore                            0x0000000183af3918 -[UIApplication sendEvent:] + 824
11  UIKitCore                            0x0000000183916464 __dispatchPreprocessedEventFromEventQueue + 7900
12  UIKitCore                            0x000000018390b250 __processEventQueue + 6756
13  UIKitCore                            0x00000001839106fc __eventFetcherSourceCallback + 168
14  CoreFoundation                       0x00000001813b30d0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
15  CoreFoundation                       0x00000001813c3d90 __CFRunLoopDoSource0 + 204
16  CoreFoundation                       0x00000001812fe098 __CFRunLoopDoSources0 + 264
17  CoreFoundation                       0x00000001813038a4 __CFRunLoopRun + 816
18  CoreFoundation                       0x0000000181317468 CFRunLoopRunSpecific + 596
19  GraphicsServices                     0x000000019cea338c GSEventRunModal + 160
20  UIKitCore                            0x0000000183cb9088 -[UIApplication _run] + 1096
21  UIKitCore                            0x0000000183a37958 UIApplicationMain + 2088
22  MyApp                                0x0000000102ea2870 main (MyAppDelegate.swift:15)
23  ???                                  0x0000000103885aa4 0x0 + 0

Thread 1:
0   libsystem_kernel.dylib               0x00000001b88c5504 mach_msg_trap + 8
1   CoreFoundation                       0x00000001812ff738 __CFRunLoopServiceMachPort + 368
2   CoreFoundation                       0x0000000181303a2c __CFRunLoopRun + 1208
3   CoreFoundation                       0x0000000181317468 CFRunLoopRunSpecific + 596
4   Foundation                           0x0000000182b33c94 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 232
5   Foundation                           0x0000000182b74dc8 -[NSRunLoop(NSRunLoop) runUntilDate:] + 88
6   UIKitCore                            0x0000000183c32230 -[UIEventFetcher threadMain] + 520
7   Foundation                           0x0000000182b8340c __NSThread__start__ + 804
8   libsystem_pthread.dylib              0x00000001f1d639a4 _pthread_start + 144
9   libsystem_pthread.dylib              0x00000001f1d62ea0 thread_start + 4

Thread 2:
…

Thread 3:
…

Thread 4:
…

Thread 5:
…

Thread 0 crashed with arm64 Thread State:
   x21: 0x40000002826da4c0     x2: 0x0000000000000001    x16: 0x0000000185a20ea8     x3: 0x0000000150928fa0
   x22: 0x0000000103fa2aa8     x4: 0x0000000000000280    x17: 0x04f80001dbbb7688   cpsr: 0x0000000020000000
    x5: 0x0000000150928fa0    x23: 0x00000001509285d0     x6: 0x0000000000000029    x18: 0x000000015500b940
   x10: 0x00000000000d9f00     lr: 0x0000000102f59cc0     x7: 0x0000000000000001    x24: 0xc000000000000024
   x11: 0x0000000000179f41     x8: 0x0000000000000003    x19: 0x00000002826c3780    x25: 0x000000016cf605d0
    x9: 0x0000000000000005    x12: 0x00000000000030ef     fp: 0x000000016cf605c0    x26: 0x000000016cf60080
   x13: 0x00000000c7700670     pc: 0x0000000102f59f38    x27: 0x000000016cf60150    x14: 0x00000001041a4b60
   x20: 0x000000016cf605d0     x0: 0x0000000000000005     sp: 0x000000016cf60080    x28: 0x0000000103fa2fc0
   x15: 0x00000000c7700675     x1: 0x0000000000000005

And yes, it seems as if something gets deallocated faster than some other code would expect it to be gone. At least that's my assumption now.

I had to strip out the code from Thread 2 to 5 because of message size issues, they showed the usuals stacks anyway.