EXC_BAD_ACCESS可能的原因？

Question

我有一个使用Apple的例子SimplePing的遗留应用程序。有一个源文件SimplePing.m，其中包含下一个方法：

- (void)sendPingWithData:(NSData *)data {
    id<SimplePingDelegate>  strongDelegate;

    ...

    strongDelegate = self.delegate;
    if (...) {
        [strongDelegate simplePing:self didSendPacket:...];
    }

    self.nextSequenceNumber += 1; // CRASH
    if (self.nextSequenceNumber == 0) {
        self.nextSequenceNumberHasWrapped = YES;
    }
}

Crashlytics报告了数十起堆栈跟踪崩溃事件：

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000009de3bbeb8

libobjc.A.dylib objc_msgSend + 16
MyApp  SimplePing.m line 313 -[SimplePing sendPingWithData:]
Foundation __NSFireTimer + 88
CoreFoundation  __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28
CoreFoundation  __CFRunLoopDoTimer + 856
CoreFoundation  __CFRunLoopDoTimers + 244
CoreFoundation  __CFRunLoopRun + 1484
CoreFoundation  CFRunLoopRunSpecific + 424
GraphicsServices GSEventRunModal + 100
UIKit UIApplicationMain + 208
MyApp main.swift line 10
libdyld.dylib start + 4

我还没有设法重新推销它，到目前为止我对这个应用程序了解不多。但我必须以某种方式开始研究它。我看了一下代表们的实现（顺便说一下，他们在Swift中 - 如果它相关），到目前为止还没有发现任何罪行。

据我所知，当一个人试图访问解除分配的内存时，EXC_BAD_ACCESS通常会触发。在这个具体案例中，它可能意味着[strongDelegate simplePing:self didSendPacket:...]已经以某种方式解除分配self。但由于self是一个强有力的参考，它根本不会发生 - 我是对的吗？

你们可能会告诉我一些关于它如何在该线上与EXC_BAD_ACCESS崩溃的可能情况？唯一的想法是发生了一些内存覆盖。

更新 我的假设＆＃34;我完全错了，但因为self是一个强大的参考...＆＃34; 。 self幽灵强弱，也不弱。它只是unsafe_unretained，正如聪明人解释的那样：https://stackoverflow.com/a/18011581/674548。