帮我诊断这次崩溃
我的应用程序的很多用户都在发送此崩溃，但我无法重复它。所以我正在寻找有关如何对其进行故障排除的提示，这是崩溃日志的相关部分：
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
objc[1535]: FREED(id): message retain sent to freed object=0x640ad0
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x9116f4b4 _objc_error + 116
1 libobjc.A.dylib 0x9116f4ea __objc_error + 52
2 libobjc.A.dylib 0x9116d7dc _freedHandler + 58
3 ...my_company.my_app 0x00045635 -[MyObject mySelector] + 1494
4 com.apple.Foundation 0x90be18d4 __NSFireTimer + 141
5 com.apple.CoreFoundation 0x93a38adb __CFRunLoopRun + 8059
6 com.apple.CoreFoundation 0x93a36464 CFRunLoopRunSpecific + 452
7 com.apple.CoreFoundation 0x93a36291 CFRunLoopRunInMode + 97
8 com.apple.HIToolbox 0x92982e04 RunCurrentEventLoopInMode + 392
9 com.apple.HIToolbox 0x92982bb9 ReceiveNextEventCommon + 354
10 com.apple.HIToolbox 0x92982a3e BlockUntilNextEventMatchingListInMode + 81
11 com.apple.AppKit 0x9576e78d _DPSNextEvent + 847
12 com.apple.AppKit 0x9576dfce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
13 com.apple.AppKit 0x95730247 -[NSApplication run] + 821
14 com.apple.AppKit 0x957282d9 NSApplicationMain + 574
15 ...my_company.my_app 0x00002042 start + 54
所以，从这一行：
3 ...my_company.my_app 0x00045635 -[MyObject mySelector] + 1494
我可以推断出在 mySelector 中，一条消息被发送到一个已经被释放的对象，但我查看了代码，但我看不到它，而且还有太多其他依赖项，无法在此处发布代码。
所以我的问题是：
- 每行末尾的数字表示什么，在上面的示例中是 1494。
- 在前一行中有对 __NSFireTimer 的引用 - 这是否表明 mySelector 正在由我的代码中的 NSTimer 调用？
- 我尝试在启用 Zombies 的情况下运行我的应用程序，除了在我的代码中检查 mySelector 中的每个对象 != nil 之外，如果我无法重复崩溃，我还能做什么？
对此的任何帮助将不胜感激！
a lot of users of my app are sending in this crash but I'm unable to repeat it.. So I'm looking for tips on how I can troubleshoot it, here's the relevant section of the crash log:
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Application Specific Information:
objc[1535]: FREED(id): message retain sent to freed object=0x640ad0
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x9116f4b4 _objc_error + 116
1 libobjc.A.dylib 0x9116f4ea __objc_error + 52
2 libobjc.A.dylib 0x9116d7dc _freedHandler + 58
3 ...my_company.my_app 0x00045635 -[MyObject mySelector] + 1494
4 com.apple.Foundation 0x90be18d4 __NSFireTimer + 141
5 com.apple.CoreFoundation 0x93a38adb __CFRunLoopRun + 8059
6 com.apple.CoreFoundation 0x93a36464 CFRunLoopRunSpecific + 452
7 com.apple.CoreFoundation 0x93a36291 CFRunLoopRunInMode + 97
8 com.apple.HIToolbox 0x92982e04 RunCurrentEventLoopInMode + 392
9 com.apple.HIToolbox 0x92982bb9 ReceiveNextEventCommon + 354
10 com.apple.HIToolbox 0x92982a3e BlockUntilNextEventMatchingListInMode + 81
11 com.apple.AppKit 0x9576e78d _DPSNextEvent + 847
12 com.apple.AppKit 0x9576dfce -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
13 com.apple.AppKit 0x95730247 -[NSApplication run] + 821
14 com.apple.AppKit 0x957282d9 NSApplicationMain + 574
15 ...my_company.my_app 0x00002042 start + 54
So, from this line:
3 ...my_company.my_app 0x00045635 -[MyObject mySelector] + 1494
I can deduce that in mySelector a message is being sent to an object that's already being released, but I've looked through the code and I just can't see it and there are too many other dependencies to post the code here.
So my questions are:
- What do the numbers at the end of each line indicate, in the above example it's 1494.
- On the preceding line there's a reference to __NSFireTimer - does this indicate that mySelector is being called by a NSTimer in my code?
- I've tried running my app with Zombies enabled, aside from sprinkling my code with checks that each object != nil in mySelector, what else can I do if I can't repeat the crash?
Any help on this would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用工具来观察分配。我发现这很有帮助。
Use instruments to watch allocation. I found it helpful.
我相信每行末尾的数字表示回溯中该点函数内代码字节的偏移量。调试器将使用此信息将代码偏移量映射到实际的源代码行（它需要应用程序中的调试信息才能执行此操作）。就您而言，该信息并不是特别有用。
对 NSFireTimer 的引用意味着主线程的运行循环已安排了一个计时器，并且已调用 [myObject mySelector]。我认为从堆栈跟踪中我们可以假设计时器已直接调用“myObject”，因为没有其他中间堆栈帧。
我的猜测是该对象已被释放，但它是主线程中预定计时器的目标，而您忘记删除它。
该对象最初如何释放取决于应用程序的编译方式。它使用垃圾收集，还是依赖保留/释放内存管理？
如果您没有使用垃圾收集，那么您可能在某个地方错过了“保留”。也许你的对象已经自动释放，并且运行循环在你没有预料到的时候清理了它？
如果您可以识别所涉及的计时器，您可能需要考虑在类的 dealloc 或 Finalize 方法中禁用计时器。您还可以在其中添加一些日志记录以显示对象何时被释放。
I believe the numbers at the end of each line indicate the offset in terms of code bytes within the function at that point in the backtrace. A debugger would use this information to map the code offset to an actual line of source code (it needs debug information in the application to do this). In your case, the information is not particularly useful.
The reference to NSFireTimer means that your main thread's run loop has had a timer scheduled and it has fired calling [myObject mySelector]. I think from the stack trace we can assume that the timer has invoked "myObject" directly since there are no other intervening stack frames.
My guess would be that the object has been freed but it was the target of a scheduled timer in your main thread, which you have forgotten to remove.
How the object became freed in the first place depends on how your application is compiled. Does it use Garbage Collection, or does it rely on retain/release memory management?
If you are not using garbage collection, then you have probably missed a "retain" somewhere. Perhaps your object has been autoreleased and the runloop has cleaned it up when you didn't expect it to?
If you can identify the timer involved, you might want to consider disabling the timer in the dealloc or finalize method of your class. You could also add some logging there to show you when the object is freed.