3

私のアプリは、クラッシュの原因となった静的ライブラリをリンクしていました (.dSYM ファイルはここでは役に立ちません)。ソース コードがあるので、バイト オフセットを使用してソース コード内の関連する行を特定することはできますか?

以下はクラッシュスタックです。関数 pjsua_acc_set_registration のソース コードがあるので、オフセット 1535 に関連する行を見つけることは可能ですか?

Exception Type:  SIGABRT
Exception Codes: #0 at 0x38d021fc
Crashed Thread:  0

Thread 0 Crashed:
0   libsystem_kernel.dylib              0x38d021fc ___pthread_kill + 8
1   libsystem_c.dylib                   0x38cb302d _abort + 77
2   libsystem_c.dylib                   0x38c92c6b ___assert_rtn + 183
3   my app                              0x00181cff pjsua_acc_set_registration + 1535
4   CoreFoundation                      0x2e3f53d4 __invoking___ + 68
5   CoreFoundation                      0x2e33f6c7 -[NSInvocation invoke] + 287
6   CoreFoundation                      0x2e342e83 -[NSInvocation invokeWithTarget:] + 51
7   my app                              0x0015f3bb -[UABaseAppDelegateSurrogate forwardInvocation:] (UABaseAppDelegateSurrogate.m:75)

...
4

1 に答える 1

2

シンボル ファイルがなければ、それを自動化する方法はないと思います。

ARM アセンブラーを知っていて、ソース コードを持っていて、多くの時間を手にしている場合は、プログラムの逆アセンブルを理解して、そのバイト オフセットがどのソース コードに対応しているかを突き止めることができます。以前はそのような分析を行っていましたが、ここ数年はそれほど深くは考えていませんでした。（さらに、ARMアセンブラを学んだことはありません）

この問題は、コードの最適化によってさらに難しくなります。デフォルトでは、リリース ビルド設定は高レベルのコード最適化をオンにします。コンパイラは、コードを並べ替えたり、ソース ステートメントを混ぜ合わせたり、ループをアンロールしたり、変数をレジスタに移動したり単純化したりして、何を見ているのかを理解するのを非常に困難にする他の多くのトリックを実行します。

于 2013-11-27T04:27:45.703 に答える