瞭解沒有應用程序調用的iOS線程轉儲

因此，我有一個應用程序在應用程序商店中生效，我已修改該應用程序以發送回崩潰報告。這幫助我擺脫了大部分的錯誤，但我很難識別這個錯誤。下面是一個典型的崩潰報告（我正在使用PLCrashReporter）。瞭解沒有應用程序調用的iOS線程轉儲

正如你可以看到崩潰的線程（線程6）沒有調用我的代碼。
顯然，我試圖理解是什麼導致這個問題，所以我可以修復它，但沒有調用我的應用程序的代碼，我只能猜測。

我還應該提到該應用程序每天使用數十萬次，但我僅獲得少數這些報告（過去24小時內有8次），所以這個問題不容易重現。我一直無法重現它。

我應該如何解決這一問題？謝謝。

碰撞報告如下：

的applicationName：MyApp的
bundleidentifier：com.mycompany.MyApp
systemversion：4.2.1
平臺：iPad1,1

過程：MyApp的[ 909]
路徑：/var/mobile/Applications/A50A5AA1-4F04-405B-A295-89E13DA0760E/MyApp.app/MyApp
標識符：com.mycom pany.MyApp
編碼類型：ARM（母語）
父進程：的launchd [1]

日期/時間：2011-03-24 11時50分49秒0000
OS版本：iPhone OS 4.2.1
報告版本：104

異常類型：SIGBUS
異常代碼：BUS_ADRALN在0x10的
崩潰螺紋：6

線程0：
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1的CoreFoundation 0x3580264f 0x357da000 165455
2的CoreFoundation 0x35801ed9 0x357da000 163545
3的CoreFoundation 0x35801c87 0x357da000 162951
4的CoreFoundation 0x35801b8f 0x357da000 162703
5 GraphicsServices 0x320c84ab 0x320c4000 17579
6 GraphicsServices 0x320c8557 0x320c4000 17751
7的UIKit 0x341dc329 0x341a5000 226089
8的UIKit 0x341d9e93 0x341a5000 216723
9 MyApp的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的CoreFoundation 0x3580264f 0x357da000 165455
2的CoreFoundation 0x35801ed9 0x357da000 163545
3的CoreFoundation 0x35801c87 0x357da000 162951
4的CoreFoundation 0x35801b8f 0x357da000 162703
5的WebCore 0x34bf612b 0x34b3f000 749867
6 libSystem.B.dylib 0x30d7d88d 0x30d03000 501901

線程3：
0 libSystem.B.dylib 0x30d04268 0x30d03000 4712
1的CoreFoundation 0x3580264f 0x357da000 165455
2的CoreFoundation 0x35801ed9 0x357da000 163545
3的CoreFoundation 0x35801c87 0x357da000 162951
4的CoreFoundation 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的CoreFoundation 0x3580969f 0x357da000 194207
2的CoreFoundation 0x357e60fc 0x357da000 49404
3的CoreFoundation 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的CoreFoundation 0x35818bbf 0x357da000 256959
19 QuartzCore 0x31075685 0x31066000 63109
20 QuartzCore 0x3107543d 0x31066000 62525
21 QuartzCore 0x3106f56d 0x31066000 38253
22 QuartzCore 0x3106f383 0x31066000 37763
23 QuartzCore 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 5 01901

螺紋6墜毀與ARM（母語）線程狀態：
R0：0x0012aa00 R1：0x344b9f09 R2：0x001f4790 R3：0x34247ead
R4：0x00000008 R5：00000001 R6：0x001df3a0 R7：0x2ff646bc
R8：0x344b9f09 R9 ：0x00000008 R10：0x0012aa00 R11：0x2ff64710
R12：0x3e82ac58 SP：0x2ff6461c LR：0x34247ecb PC：0x34a80464

來源

2011-03-24 jeka

我們在這裏有一個非常類似的崩潰。出於好奇，你在使用什麼第三方庫（如果有的話）？你在使用ASIHTTPRequest嗎？ – Zeppomedio 2011-03-25 17:28:54

不，我沒有使用ASIHTTPRequest。除了PLCrashReporter，我還使用Google的移動應用程序廣告庫（AFMA） – jeka 2011-03-28 17:41:38

我遇到了同樣的問題，但我可以重現它。我有一個自定義電影播放器，實現了廣告疊加。當顯示這些疊加層中的一個時，定時器被安排在指定的持續時間後（淡出）分派代碼塊以隱藏疊加層。如果電影播放器在該定時器觸發之前關閉並隨後解除分配，則該程序在觸發時會崩潰。所以這可能是因爲你對一些不存在的對象進行了一些延遲的UIKit調用。 – darvids0n 2011-09-08 06:22:16

如果您使用的Xcode> 3.2.1但< 4.0，則可以拖動該崩潰報告文件到管理窗口，到設備日誌部分，它會自動爲您進行符號化，從而爲您提供相關信息您在那裏看到的堆棧痕跡非常漂亮。

否則，請按照this question的說明手動對其進行符號化。

來源

2011-03-24 12:49:54

我收到的崩潰報告與標準iOS報告不盡相同，即使它們看起來很相似。所以組織者和symboliccrash都不能理解它。但是，只要崩潰的線程調用了我的代碼，這是沒問題的，因爲我使用「atos」來確定我的代碼導致錯誤的調用。在這種特殊情況下，崩潰的線程沒有調用我的代碼，所以我只能猜測是什麼導致了崩潰，我無法象徵基金會符號。 – jeka 2011-03-24 14:04:15

這不是一個灌籃高手，但是線程6可能會釋放一些免費的橋接對象（如NSString/CFStringRef）。這個對象可能已經被你的代碼過度發佈了，而且超出租約要麼是活潑的，要麼就是通常是良性的。

如果不這樣做，你能否改變你的崩潰報告系統來收集設備類型數據和（非識別）設備特定數據（如果你發現你沒有一個UUID存儲在prefs文件中）？然後你就可以知道它是來自單個用戶還是非常小的用戶池（可能是他們特定設備的硬件問題），或者是很多用戶（而不是硬件問題），或者是所有相同的操作系統版本（也許是一個操作系統錯誤，或者至少是行爲上的差異，你正在測試的範圍被縮小了，或者你可以放棄該操作系統版本或該操作系統上的特定功能）。

來源

2011-12-16 23:20:12 Stripes

瞭解沒有應用程序調用的iOS線程轉儲

回答

相關問題