【问题标题】:understanding iOS thread dump that has no application calls了解没有应用程序调用的 iOS 线程转储
【发布时间】:2011-03-24 12:36:37
【问题描述】:

所以我在应用商店中有一个应用,我已对其进行了修改以发回崩溃报告。这帮助我摆脱了大部分错误,但我很难确定这个错误。下面是一个典型的崩溃报告(我使用的是 PLCrashReporter)。

如您所见,崩溃的线程(线程 6)没有调用我的代码。
显然,我试图了解导致此问题的原因,以便修复它,但没有调用我的应用程序代码,我只能猜测。

我还应该提到,该应用程序每天使用数十万次,但我只收到少数这些报告(过去 24 小时内有 8 次),所以这个问题不容易重现。我根本无法重现它。

我应该如何解决这个问题?谢谢。

崩溃报告如下:


应用程序名称:MyApp
捆绑标识符:com.mycompany.MyApp
系统版本:4.2.1
平台:iPad1,1

进程:MyApp[909]
路径:/var/mobile/Applications/A50A5AA1-4F04-405B-A295-89E13DA0760E/MyApp.app/MyApp
标识符:com.mycompany.MyApp
代码类型:ARM(本机)
父进程:launchd [1]

日期/时间:2011-03-24 11:50:49 0000
操作系统版本:iPhone OS 4.2.1
报告版本:104

异常类型:SIGBUS
异常代码:0x10 处的 BUS_ADRALN
崩溃线程:6

线程 0:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 核心基础 0x3580264f 0x357da000 165455
2 核心基础 0x35801ed9 0x357da000 163545
3 核心基础 0x35801c87 0x357da000 162951
4 核心基础 0x35801b8f 0x357da000 162703
5 图形服务 0x320c84ab 0x320c4000 17579
6 图形服务 0x320c8557 0x320c4000 17751
7 UIKit 0x341dc329 0x341a5000 226089
8 UIKit 0x341d9e93 0x341a5000 216723
9 我的应用程序 0x00002371 0x1000 4977

线程 1:
0 libSystem.B.dylib 0x30d30974 0x30d03000 186740
1 libSystem.B.dylib 0x30dda17c 0x30d03000 881020
2 libSystem.B.dylib 0x30dd9ba0 0x30d03000 879520
3 libSystem.B.dylib 0x30d7e251 0x30d03000 504401

线程 2:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 核心基础 0x3580264f 0x357da000 165455
2 核心基础 0x35801ed9 0x357da000 163545
3 核心基础 0x35801c87 0x357da000 162951
4 核心基础 0x35801b8f 0x357da000 162703
5 WebCore 0x34bf612b 0x34b3f000 749867
6 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

线程 3:
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1 核心基础 0x3580264f 0x357da000 165455
2 核心基础 0x35801ed9 0x357da000 163545
3 核心基础 0x35801c87 0x357da000 162951
4 核心基础 0x35801b8f 0x357da000 162703
5 基础 0x3118e5fd 0x31161000 185853
6 基础 0x3116c199 0x31161000 45465
7 基础 0x31165249 0x31161000 16969
8 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

线程 4:
0 libSystem.B.dylib 0x30d2868c 0x30d03000 153228
1 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

线程 5:
0 libSystem.B.dylib 0x30d7e9e0 0x30d03000 506336

线程 6 崩溃:
0 libobjc.A.dylib 0x34a80464 0x34a7d000 13412
1 核心基础 0x3580969f 0x357da000 194207
2 核心基础 0x357e60fc 0x357da000 49404
3 核心基础 0x35809623 0x357da000 194083
4 UIKit 0x341bf8d3 0x341a5000 108755
5 UIKit 0x341bf635 0x341a5000 108085
6 UIKit 0x341bf583 0x341a5000 107907
7 UIKit 0x341bf583 0x341a5000 107907
8 UIKit 0x341bf433 0x341a5000 107571
9 UIKit 0x341aa82f 0x341a5000 22575
10 UIKit 0x341c172b 0x341a5000 116523
11 UIKit 0x3420c7cd 0x341a5000 423885
12 UIKit 0x3420c6cb 0x341a5000 423627
13 UIKit 0x3420ed03 0x341a5000 433411
14 UIKit 0x3420e7f3 0x341a5000 432115
15 UIKit 0x3420cd2d 0x341a5000 425261
16 UIKit 0x3420bedd 0x341a5000 421597
17 UIKit 0x341b80cf 0x341a5000 78031
18 核心基础 0x35818bbf 0x357da000 256959
19 石英核心 0x31075685 0x31066000 63109
20 石英核心 0x3107543d 0x31066000 62525
21 石英核心 0x3106f56d 0x31066000 38253
22 石英核心 0x3106f383 0x31066000 37763
23 石英核心 0x310c332d 0x31066000 381741
24 libSystem.B.dylib 0x30d2c26f 0x30d03000 168559
25 libSystem.B.dylib 0x30d2bf2f 0x30d03000 167727
26 libSystem.B.dylib 0x30d2be91 0x30d03000 167569
27 基础 0x3116c1bd 0x31161000 45501
28 基础 0x31165261 0x31161000 16993
29 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

线程 6 因 ARM(本机)线程状态而崩溃:
r0: 0x0012aa00 r1: 0x344b9f09 r2: 0x001f4790 r3: 0x34247ead
r4: 0x00000008 r5: 0x00000001 r6: 0x001df3a0 r7: 0x2ff646bc
r8: 0x344b9f09 r9: 0x00000008 r10: 0x0012aa00 r11: 0x2ff64710
r12: 0x3e82ac58 sp: 0x2ff6461c lr: 0x34247ecb pc: 0x34a80464

【问题讨论】:

  • 我们这里有一个非常相似的崩溃。出于好奇,您使用的是哪些 3rd 方库(如果有)?你在使用 ASIHTTPRequest 吗?
  • 不,我没有使用 ASIHTTPRequest。除了 PLCrashReporter,我还使用 Google 的移动应用广告库 (AFMA)
  • 我遇到了同样的问题,但我可以重现它。我有一个自定义电影播放器​​,它实现了广告叠加。当显示这些叠加层之一时,会安排一个计时器调度代码块以在指定的持续时间后隐藏叠加层(它会淡出)。如果电影播放器​​在该计时器触发之前关闭并随后被释放,则程序在触发时崩溃。因此,这可能与您对不再存在的对象进行的一些延迟的 UIKit 调用有关。
  • 我可以确认正确释放我的代码块可以消除 BUS_ARDALN 崩溃。

标签: ios crash-dumps crash-reports iphone


【解决方案1】:

如果您使用的是 Xcode > 3.2.1 但

否则,请按照this question 的说明手动对其进行符号化。

【讨论】:

  • 我收到的崩溃报告与标准 iOS 报告不同,尽管它们看起来很相似。所以,Organizer 和 symbolicatecrash 都无法理解。但是,只要崩溃的线程调用了我的代码,这没问题,因为我使用“atos”来确定我的代码导致错误的调用。在这种特殊情况下,崩溃的线程没有调用我的代码,所以我只能猜测是什么导致了崩溃,我无法用符号表示 Foundation 符号。
【解决方案2】:

这不是灌篮,但线程 6 可能正在释放一些免费桥接对象(如 NSString/CFStringRef)。该对象可能已被您的代码过度释放,并且该过度租用要么是不正当的,要么发生在其中的东西通常是良性的。

如果做不到这一点,您是否可以更改崩溃报告系统以收集设备类型数据和(非识别性)设备特定数据(例如,如果您发现自己没有 UUID,则将其存储在 prefs 文件中)?然后你可以判断它是来自单个用户还是非常小的用户池(可能是他们特定设备的硬件问题),或者很多用户(不是硬件问题),或者所有相同的操作系统版本(可能是操作系统错误,或者至少是行为差异,并且您正在测试的范围缩小了,或者您可以放弃该操作系统版本或该操作系统上的特定功能)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-01-17
    • 2015-12-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-25
    • 2013-01-05
    相关资源
    最近更新 更多