2012-03-01 73 views
0

我有一個在幾臺設備上崩潰的iOS應用程序。考慮到在iTunes發生這種情況時我看到的糟糕評論,崩潰似乎在代碼中的相同位置發生。使用GCD時在某些設備上發生故障

最後,一個好人實際上聯繫了我,而不僅僅是留下評論,他們甚至在爲我安裝使用TestFlight的應用程序的調試版時。

武裝與崩潰報告中,我可以看到它深的地方發生的malloc:給定的行號

2 libSystem.B.dylib 0x34683d6e _sigtramp + 42 
3 libSystem.B.dylib 0x3468c886 szone_malloc_should_clear + 2122 

而且,它出現在我開始一個後臺任務點發生:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{ 
    UIImage *image = [self loadImage:path]; 
    dispatch_sync(dispatch_get_main_queue(), ^{ 

我不確定碰撞發生在那三條線中的哪條線上,所以目前還不清楚是否在GCD本身的調用中發生崩潰,就在塊代碼的開始處,或者塊本身的某處。

堆棧跟蹤結束在包含上面代碼片段的函數中,而不是,看起來,在塊本身。如果崩潰在異步模塊中,堆棧跟蹤是否仍將調用樹包含在父函數中?我目前正在研究這樣一個假設,即塊內部崩潰的堆棧跟蹤不會包含調用父函數(因爲塊在其自己的線程中異步執行),所以我認爲這是對GCD的調用崩潰。

我試過使用TFLog來查找確切的故障時刻,但是根本沒有記錄日誌。我知道日誌調用是正確完成的,因爲在我的開發設備上,我看到日誌彈出在TestFlight記錄器中,所以看起來崩潰擾亂了這個調試選項。

最後,TestFlight無法找到該用戶使用的iPhone 4的iOS版本號 - 所以我想知道這是否是越獄設備,並且如果它可能可能會有效果? (我問過用戶,但沒有答案)。

請注意,這是所有的ARC代碼,所以我很驚訝地發現這是一個內存管理問題。它也與一些設備隔離,但這些設備每次都會在同一時刻崩潰。

任何人都可以提供任何見解或調試建議(假設我自己沒有崩潰設備)。

感謝,

回答

0

我已經解決了這個可怕的錯誤。

事實證明,DISPATCH_QUEUE_PRIORITY_BACKGROUND僅在5.0或更高版本上可用,並且會在以前的版本中崩潰。

我實際上已經在運行4.2.1的iPhone 3G上測試了該應用程序,但是由於該模型不支持GCD,所以該特定代碼路徑並未運行......