17

AppStoreでCrittercismのクラッシュレポートを含むアプリをリリースしたばかりですが、SIGSEGVエラーに関連するクラッシュレポートがかなりの数あります。Crittercismは、StackTraceと、使用統計などに関するいくつかの便利な詳細を提供しますが、これらのシンボル化されたスタックトレースにはまだ戸惑っています。この種のことについて一般的にいくつか質問があります-

  1. スタックトレースのクラスとメソッドの多くは、私のアプリでは使用されていません（私の知る限り）。これにより、これらのクラッシュはAppleのプライベートAPIが原因であると私は信じています。この質問の下部にあるスタックトレースを見てください。 クラッシュレポートのすべてのメソッドとクラスがコードに直接実装されていない場合、アプリがクラッシュしている原因を特定するにはどうすればよいですか？

  2. +クラッシュしたスレッドの各行の終わりにある数字の付いた記号は何を表していますか？

  3. SIGSEGVのクラッシュについて尋ねるStackOverflowのほとんどのQ/Aは、メモリリークまたは問題が原因であると述べていますが、iOSプロジェクトでARCを使用している場合、メモリの問題が原因でクラッシュするのはどうしてですか？ ARCは私のためにそれらすべてを管理することになっているのではありませんか？

  4. エラー/クラッシュを再現できない場合はどうすればよいですか？

  5. StackTraceを実際に読み取る方法はありますか？何が起こっているのかを理解するのに役立つ一般的なものはありますか？

これは、この質問に関連するCrittercismのメインスレッドクラッシュレポートのStackTraceです。

Thread: Unknown Name (Crashed)
0     UIKit                                 0x37307a22 -[UIView(CALayerDelegate) actionForLayer:forKey:] + 138
1     QuartzCore                            0x38fdfff7 -[CALayer actionForKey:] + 75
2     QuartzCore                            0x38fdffa7 _ZL12actionForKeyP7CALayerPN2CA11TransactionEP8NSString + 59
3     QuartzCore                            0x38fdfe93 _ZN2CA5Layer12begin_changeEPNS_11TransactionEjRP11objc_object + 131
4     QuartzCore                            0x38fdab87 _ZN2CA5Layer6setterEj12_CAValueTypePKv + 183
5     QuartzCore                            0x39007057 -[CALayer setBackgroundColor:] + 35
6     UIKit                                 0x3731ef51 -[UIView(Internal) _setBackgroundCGColor:withSystemColorName:] + 1021
7     APP NAME                              0x000a301d 0x00086000 + 118813
8     libdispatch.dylib                     0x3962511f _dispatch_call_block_and_release + 11
9     libdispatch.dylib                     0x39628ecf _dispatch_queue_drain$VARIANT$mp + 143
10   libdispatch.dylib                      0x39628dc1 _dispatch_queue_invoke$VARIANT$mp + 41
11   libdispatch.dylib                      0x3962991d _dispatch_root_queue_drain + 185
12   libdispatch.dylib                      0x39629ac1 _dispatch_worker_thread2 + 85
13   libsystem_c.dylib                      0x3824da11 _pthread_wqthread + 361
4

2 に答える 2

6

このクラッシュレポートを象徴する必要があります。番号7は関心のある行ですが、シンボル情報がないため、クラッシュレポートを有用なものに変換することはできません。象徴化するには、アプリストアのリリースで使用された正確なコードが必要です。あなたがそれを持っているなら、あなたはこの答えを参照することができます：

https://stackoverflow.com/a/13280585/1155387

その他について：

1）内部APIのバグをすぐに想定しないでください。関数は明らかにビューの背景色を変更し、内部でさまざまなメソッドを呼び出します。どういうわけか無効な値が渡された可能性があります。あなたが書いたコードがこれまでに実行された唯一のコードであると考えるほど素朴なことはしないでください。

2）+記号は、バイナリオブジェクト内のそのコードのオフセットを示します。あなたには役に立たない。

3）ARCはObjective-Cのスコープしか処理しないため、ARCではメモリエラーが発生しやすくなります。CoreFoundationオブジェクトなどは管理されません。それは必ずしもここで起こることではありませんが、ARCはあなたが一緒に記憶について考えるのをやめなければならないという意味ではありません。

4）上記を参照

5）上記を参照

于 2012-12-10T03:32:05.727 に答える
4

私はあなたがこのようなことをしたことをいとわないでしょう：

CALayer *layer = [CALayer layer];
layer.delegate = self;

そして、CALayerへの最後の参照が削除される前に、オブジェクト「self」の割り当てが解除されました。デリゲートプロパティは、layer.delegate値として設定したオブジェクトへの参照を保持しません。これはARCとは何の関係もありません（ARCはアプリでのすべてのポインターの使用を魔法のように修正するわけではありません）。

したがって、最初に行うことは、CALayerデリゲートを設定するコードを確認し、「self」オブジェクトの割り当てが解除されたときに、このデリゲートrefをnilに戻すように設定することです。これにより、CALayerとオブジェクトの関連付けが解除されます。通常、dsymをCrittercismにアップロードする必要がありますが、この場合はそれほど重要ではありません。

于 2013-06-19T06:52:41.457 に答える