iPhone 崩溃堆栈跟踪 VS 崩溃报告

发布于 2024-10-28 09:58:47 字数 3653 浏览 1 评论 0原文

只是花了一些时间......在崩溃上,但没有理解它。这是一个经典:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010

这导致我遇到内存问题,解决无效地址0x10

令我困扰的是我有崩溃报告和堆栈跟踪,它们不同:


崩溃报告,由用户发送(成功表示,这种情况发生了):

Thread 0 Crashed:
0   libobjc.A.dylib                 0x000027d8 objc_msgSend + 16
1   UIKit                           0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54
2   QuartzCore                      0x0002d8c2 run_animation_callbacks(double, void*) + 286
3   QuartzCore                      0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116
4   CoreFoundation                  0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
5   CoreFoundation                  0x000562a6 __CFRunLoopDoTimer + 854
6   CoreFoundation                  0x0002779e __CFRunLoopRun + 1082
7   CoreFoundation                  0x00027270 CFRunLoopRunSpecific + 224
8   CoreFoundation                  0x00027178 CFRunLoopRunInMode + 52
9   GraphicsServices                0x000045ec GSEventRunModal + 108
10  GraphicsServices                0x00004698 GSEventRun + 56
11  UIKit                           0x0000411c -[UIApplication _run] + 396
12  UIKit                           0x00002128 UIApplicationMain + 664
13  MyApp                           0x00003158 main (main.m:13)
14  MyApp                           0x00003120 0x1000 + 8480

崩溃堆栈跟踪(由异常处理程序实时捕获)

0   MyApp                               0x000d79c3 0x0 + 883139
1   MyApp                               0x000d790b 0x0 + 882955
2   libSystem.B.dylib                   0x302765d3 _sigtramp + 42
3   UIKit                               0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60
4   QuartzCore                          0x33a178c9 _ZL23run_animation_callbacksdPv + 292
5   QuartzCore                          0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122
6   CoreFoundation                      0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
7   CoreFoundation                      0x3084e2ad __CFRunLoopDoTimer + 860
8   CoreFoundation                      0x3081f7a5 __CFRunLoopRun + 1088
9   CoreFoundation                      0x3081f277 CFRunLoopRunSpecific + 230
10  CoreFoundation                      0x3081f17f CFRunLoopRunInMode + 58
11  GraphicsServices                    0x31e445f3 GSEventRunModal + 114
12  GraphicsServices                    0x31e4469f GSEventRun + 62
13  UIKit                               0x31e51123 -[UIApplication _run] + 402
14  UIKit                               0x31e4f12f UIApplicationMain + 670
15  MyApp                               0x0000315f 0x0 + 12639
16  MyApp                               0x00003128 0x0 + 12584

两者不同,堆栈跟踪指向我的代码中的崩溃,但位于我的地址既不能象征也不能识别。我认为崩溃报告表明一条消息已发送到已发布的实例...可能与使用有关:

+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selector

所以这里(最后!)是我的问题:

  1. 什么解释了日志之间的差异? (libobjc.A vs libSystem.B ??)
  2. SIGBUS 来自我的代码还是来自 UIKit?
  3. 我如何破译堆栈跟踪高地址(0x000d79??,atos 无法解析)
  4. 这就是我所认为的与动画未能结束相关的问题吗?类似于此> 如何取消 UIView setAnimationDelegate: 调用上的委托?
  5. AFAIK,setAnimationDelegate 应该保留委托...有人确认吗?

编辑:我无法使用NSZombiesEnabled,这是来自已发布应用程序的崩溃报告,我无法在开发环境中重现崩溃。我只有这些日志可以诊断。

Just spent some time... on a crash, without understanding it. That's a classic:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000010

Which leads me to a memory issue, addressing the invalid adress 0x10

What bothers me is that I have crash report and stack trace, which differ:


The crash report, sent by user (symbolicated successfully, that happens) :

Thread 0 Crashed:
0   libobjc.A.dylib                 0x000027d8 objc_msgSend + 16
1   UIKit                           0x0005e9d2 -[UIViewAnimationState animationDidStop:finished:] + 54
2   QuartzCore                      0x0002d8c2 run_animation_callbacks(double, void*) + 286
3   QuartzCore                      0x0002d764 CA::timer_callback(__CFRunLoopTimer*, void*) + 116
4   CoreFoundation                  0x000567f4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
5   CoreFoundation                  0x000562a6 __CFRunLoopDoTimer + 854
6   CoreFoundation                  0x0002779e __CFRunLoopRun + 1082
7   CoreFoundation                  0x00027270 CFRunLoopRunSpecific + 224
8   CoreFoundation                  0x00027178 CFRunLoopRunInMode + 52
9   GraphicsServices                0x000045ec GSEventRunModal + 108
10  GraphicsServices                0x00004698 GSEventRun + 56
11  UIKit                           0x0000411c -[UIApplication _run] + 396
12  UIKit                           0x00002128 UIApplicationMain + 664
13  MyApp                           0x00003158 main (main.m:13)
14  MyApp                           0x00003120 0x1000 + 8480

The crash stack trace (catched live by an Exception Handler)

0   MyApp                               0x000d79c3 0x0 + 883139
1   MyApp                               0x000d790b 0x0 + 882955
2   libSystem.B.dylib                   0x302765d3 _sigtramp + 42
3   UIKit                               0x31eab9d9 -[UIViewAnimationState animationDidStop:finished:] + 60
4   QuartzCore                          0x33a178c9 _ZL23run_animation_callbacksdPv + 292
5   QuartzCore                          0x33a1776b _ZN2CAL14timer_callbackEP16__CFRunLoopTimerPv + 122
6   CoreFoundation                      0x3084e7fb __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
7   CoreFoundation                      0x3084e2ad __CFRunLoopDoTimer + 860
8   CoreFoundation                      0x3081f7a5 __CFRunLoopRun + 1088
9   CoreFoundation                      0x3081f277 CFRunLoopRunSpecific + 230
10  CoreFoundation                      0x3081f17f CFRunLoopRunInMode + 58
11  GraphicsServices                    0x31e445f3 GSEventRunModal + 114
12  GraphicsServices                    0x31e4469f GSEventRun + 62
13  UIKit                               0x31e51123 -[UIApplication _run] + 402
14  UIKit                               0x31e4f12f UIApplicationMain + 670
15  MyApp                               0x0000315f 0x0 + 12639
16  MyApp                               0x00003128 0x0 + 12584

Both differ, and the stack trace points to the crash in my code, but at addresses I can neither symbolicate nor identify. I think the crash report indicates that a message was sent to a released instance... Probably related to the use of :

+ (void)setAnimationDelegate:(id)delegate
+ (void)setAnimationDidStopSelector:(SEL)selector

So here (finally!) are my questions:

  1. What explains the differences between logs? (libobjc.A vs libSystem.B ??)
  2. Does the SIGBUS comes from my code or from UIKit?
  3. How can I decipher the stack trace upper addresses (0x000d79??, which atos doesn't resolve)
  4. Is that what I think, an issue related to an animation failing to end? similar to this > How to unset delegate on UIView setAnimationDelegate: call?
  5. AFAIK, setAnimationDelegate is supposed to retain delegate... Someone to confirm?

EDIT: I can't use NSZombiesEnabled, this is a crash report from a published app, a crash that I didn't manage to reproduce on development environment. I just have these logs to diagnose.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

誰認得朕 2024-11-04 09:58:47

每当我在顶部看到 objc_msgSend 时,我对剩余堆栈的信任度就很低,因为给出的错误往往会对堆栈造成不良影响。

GuardMalloc 对此很有用,因为尝试对已释放的空间执行任何操作都会使应用程序在调试器中立即崩溃。堆栈将完好无损。 (这使得应用程序非常慢,但它是一个非常强大的工具。)

直到 UIViewAnimationState 方法调用为止,两个堆栈都是相同的。来自异常处理程序的版本显示 C++ 损坏的名称,而不是崩溃日志中显示的常规名称。

(据我了解) _sigtramp 是系统调用信号处理程序的方法,是 Signal Trampoline 的缩写。除此之外的堆栈条目可能是您的信号处理程序代码。

Whenever I see objc_msgSend at the top, my trust of the remaining stack is low, as the error that gives this tends to do bad things to the stack.

GuardMalloc is good for this since the attempt to do anything with deallocated space will crash the app immediately in the debugger. The stack will be intact. (This makes the app very slow, but it is a very powerful tool.)

The two stacks are the same up to the UIViewAnimationState method call. The version that came from your exception handler is showing C++ mangled names instead of the regular names shown in the crash log.

(As I understand it) _sigtramp is the system's method of calling your signal handler and is short for Signal Trampoline. The stack entries beyond that are probably your signal-handler code.

岁月静好 2024-11-04 09:58:47

几周后回答我自己的问题,因为我没有相关答案,大多数都是猜测,我希望有更准确的答案,但我想我的问题不清楚:

  1. 差异来自日志的起源,sighandler 与 CrashReporter 服务,它们发生在不同的时间,那么堆栈跟踪会略有不同。
  2. SIGBUS 来自 UIKit,但很有可能是在我的代码发起的回调上,该回调以已发布的对象结束。当您无法重现问题时,这种堆栈跟踪很难调试,因为它基本上告诉您“由于动画,我在某处崩溃了” >”,哪一个,哪里……我还没弄清楚。可能在任何地方,也可能是 Apple iOS 的 bug。
  3. 堆栈中的第一个地址只是一个死胡同,当调用已释放的对象时,任何 SIGBUS 堆栈跟踪都会结束。它们在编译(版本)之间有所不同,但在任何设备上都是相同的,这就是它们不能被符号化的原因。 (我很想对此进行技术解释,而不是我的猜测
  4. ) 5.我想​​我通过在某些情况下更“积极”地取消动画来解决这个错误,例如在某些视图的取消分配上......

希望对某人有所帮助。

Answering my own question, weeks laters, since I had no relevant answers, most are guesses, I wished I had more precise answers, but I guess my question was unclear :

  1. Difference is coming from the origin of the log, a sighandler vs CrashReporter service, which are happening at different times, then the stack traces are slightly different.
  2. SIGBUS comes from UIKit, but chances are big that's on a callback initiated from my code that ends on a released object. These kind of stack traces are a pain to debug when you can't reproduce the issue, since it basically tells you "I'm crashing somewhere because of an animation", which one, where... I still didn't figured precisely. Could be anywhere, and also could be an Apple iOS bug.
  3. The first addresses in the stack are just a dead-end where any SIGBUS stack-trace ends when a released object is called. They differs across compilations (versions), but are the same on any device, That's why they can't be symbolicated. (I would love to have a technical explanation of this, instead of my guess)
  4. & 5. I guess I solved this bug byt being more "agressive" on canceling animations in certain cases like on deallocation of some Views...

Hope that helps someone.

银河中√捞星星 2024-11-04 09:58:47

您应该尝试 NSZombie,以获取有关您释放的对象的信息。当您获得 EXC_BAD_ACCESS 时,这是一个非常有用的工具。

要激活 NSZombie,请执行以下操作:

  1. 获取可执行文件的信息。
  2. 转到参数选项卡。
  3. 在“环境中设置的变量:”部分添加:

名称:NSZombieEnabled
值:YES

然后照常运行您的应用程序,当它崩溃时,它应该告诉您哪个已释放的对象收到了消息。

You should try NSZombie, to get information about what object you've released. This is a very useful tool when you get EXC_BAD_ACCESS.

To activate NSZombie do the following:

  1. Get info of the executable.
  2. Go to the arguments tab.
  3. In the "Variables to be set in the environment:" section add:

Name: NSZombieEnabled
Value: YES

Then run your app as usual and when it crashes it should tell you which deallocated object received the message.

尐偏执 2024-11-04 09:58:47

1. 我不是 100% 确定,但我认为差异是由于应用程序的运行方式造成的。在第二个日志中,看起来您正在调试模式下通过 XCode 运行应用程序,已发送 sigtramp 信号以指示 EXC_BAD_ACCESS 错误。

2. 您的代码 - 错误可能来自 UIKit 库,但它是由于您的使用问题造成的。

3. 这就是 NSZombieEnabled 将使您的生活变得更加轻松的地方!如果您使用 NSZombieEnabled 标志集运行应用程序,XCode 将保留“僵尸”对象来代替已释放的对象。当向僵尸对象发送消息时,进程将捕获错误并让您确切地知道向哪个对象发送了消息。

如果您使用的是 XCode 4,请按照以下说明启用 NSZombieEnabled...

如何在 Xcode 中设置 NSZombieEnabled 4?

对于旧版本,请按照以下说明操作...

http://www.cocoadev .com/index.pl?NSZombieEnabled

4. 确实,您的动画委托在动画完成之前已被释放。

1. I'm not 100% sure but I think the discrepancy is due to how the application is being run. In the second log it looks like you're running the application via XCode in debug mode, a sigtramp signal has been sent to indicate a EXC_BAD_ACCESS error.

2. Your code - the error may come from the UIKit library but it's a result of a problem with your usage.

3. This is where NSZombieEnabled will make your life a lot easier! If you run your application with the NSZombieEnabled flag set XCode will keep 'zombie' objects in place of deallocated objects. When a zombie object is sent a message the process will trap the error and let you know exactly what object was sent the message.

If you're using XCode 4 enable NSZombieEnabled using the following instructions...

How do I set up NSZombieEnabled in Xcode 4?

For older versions follow these instructions...

http://www.cocoadev.com/index.pl?NSZombieEnabled

4. It does indeed appear that your animation delegate has been deallocated prior to the animation completing.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文