iPhone - 當您找不到它時調試崩潰

Question

我的應用程序Crash Pad Drums報告了一次崩潰 。 它引用了某些cy鈸聲音導致iPod 4崩潰的問題。一個問題。 我在iPod touch 2上找不到崩潰，而且我沒有iTouch 4。

我能做些什么呢？

另外，我的應用程序今天是免費的。 如果有人可以下載它並找到崩潰的情況，我將欠你的債務。

編輯：澄清

我實際上無法導致崩潰，因為我沒有更新的設備可供測試。 我懷疑這是我現在正在研究的iOS 5問題，但是將來如果我是廉價的並且不願意購買新的iTouch，我該怎么辦？

編輯：

Console log:
2011-10-14 23:08:25.797 Crash Pad[794:12203] -[NSConcreteValue doubleValue]: unrecognized selector sent to instance 0xec9e2e0
2011-10-14 23:08:25.798 Crash Pad[794:12203] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[NSConcreteValue doubleValue]: unrecognized selector sent to instance 0xec9e2e0'
*** First throw call stack:
(0x1c49052 0x21fdd0a 0x1c4aced 0x1baff00 0x1bafce2 0x16f4f0 0x15d99e 0x14e0d8 0x168d42 0x15ace2 0x5c28c7 0x5c2a31 0x5c2d45 0x1be0f4a 0x1bac665 0x1bac056 0x5c2c43 0x249c8 0x24a58 0x8a72 0x1c4aec9 0x67a299 0x67a306 0x1c4aec9 0x67a299 0x67a306 0x5b6a30 0x5b6c56 0x59d384 0x590aa9 0x28c3fa9 0x1c1d1c5 0x1b82022 0x1b8090a 0x1b7fdb4 0x1b7fccb 0x28c2879 0x28c293e 0x58ea9b 0x1f0d 0x1e85)
terminate called throwing an exceptionCurrent language:  auto; currently objective-c

Answer 1

你發現的是一個Apple bug。 您可以通過設置任何視圖的動畫來輕松復制，如下所示：

CABasicAnimation *anim = [CABasicAnimation animationWithKeyPath:@"transform.scale"];
anim.duration = 0.2;
anim.repeatDuration = HUGE_VALF;
anim.autoreverses = YES;
anim.toValue = [NSValue valueWithCATransform3D:CATransform3DMakeScale(0.9, 0.9, 0.0)];
[view.layer addAnimation:anim forKey:@"throb"]; // if this isn't nil we crash on tap

運行該項目。 點擊悸動的視圖。 崩潰。 這個代碼在iOS 3和iOS 4上完全沒問題。現在的解決方法是將forKey:設置為nil，但這可能是不可接受的，因為這個參數很重要 - 非零鍵意味着如果你以后添加另一個動畫使用相同的鍵，此動畫將被刪除，這可能正是您嘗試做的。

我已向Apple提交了錯誤報告，我建議您也這樣做。

編輯（2/3/12）：好的，Apple說這是我的錯誤，而不是他們的錯誤。 由於我正在提供變換，我需要使用@"transform"的鍵，而不是@"transform.scale" 。 而且，我的3D比例變換的z值應該是1，而不是0。

Answer 2

在調試器中設置NSZombieEnabled ， MallocStackLogging和guard malloc 。 然后，當您的應用程序崩潰時，在gdb控制台中鍵入：

(gdb) info malloc-history 0x543216

將0x543216替換為導致崩潰的對象的地址，您將獲得更有用的堆棧跟蹤，它可以幫助您查明代碼中導致問題的確切行。

Answer 3

你有一個或兩個可以發布的崩潰日志嗎？ 這會有所幫助。

鑒於它在較舊的硬件上崩潰而不是舊的硬件，它不太可能是與內存相關的問題。 最有可能的是，這是與線程相關的時間問題; 更快的設備可以更快地完成某些操作，並在完成其他操作之前觸及數據結構。 鑒於聲音播放在不同設備上的持續時間是恆定的，這將進一步證實這一理論。

Answer 4

它最終成為iOS 5的一個問題。我能夠通過評論各種代碼來縮小崩潰的原因。 如有疑問，請注釋掉。