バックトレースの疑問符のみgdbがARMに報告した

Question

ARMのgdbserverを使用してクラッシュのバックトレースを取得するソフトウェアをデバッグしようとしています。残念ながら私は疑問符しか得ません。どこでも、私はこの問題を単にシンボルの欠如に関連していると読んでいますが、シンボルは私のライブラリからは削除されません。クラッシュが発生したときに、その後

reading symbols from <path>/libQtWebKit.so.4.7.2...(no debugging symbols found)...done. 

と、：：私はクライアントにシンボルをロードするファイルのコマンドを使用しようと

私が手

Program received signal SIGSEGV, Segmentation fault. 
0x00000000 in ??() 
(gdb) bt 
#0 0x00000000 in ??() 
#1 0x4bf38b88 in ??() 
Backtrace stopped: previous frame identical to this frame (corrupt stack?) 

マイライブラリがリリースでコンパイルされていますシンボルは実際にそこにあります。 nmと私はそれらを見つけることができます。なぜ私は疑問符だけを取得するのですか？これは、ライブラリが最適化されてコンパイルされているためですか？リリースモードでライブラリを使ってデバッグすることはできませんか？

Answer 1

corrupt stackメモはおそらく問題です。リターンアドレスや仮想テーブルのエントリのように見えるか、何かがゼロで上書きされた後、コントロールがそこに転送されました。利用可能なシンボルがあっても、それらのアドレスは有効なシンボルを指していません。したがって、segfault。

私はあなたの仕事を羨ましくない。これらは追跡するのが最も難しいバグであり、コードを変更してキャッチしようとするときに移動したり、一時的に消えたりすることもあります。あなたの最善の賭けは、通常、git bisectまたはVCSの同等のもので、それを導入したコミットを見つけることです。うまくいけば、それを再現することはあまり難しくありません。

Answer 2

"SEGV at address 0"の問題が発生したときに使うことができるトリックは、手動でスタックの先頭からPCに戻りアドレスをポップし、そこからスタックトレースを試みることです。これは、NULLポインタを使って間接呼び出しを行うことによって0にアドレスしなければならないことを前提としています.

私はARMをあまりよく知らないが、

(gdb) set $eip = *(void **)$esp 
(gdb) set $esp = $esp + 4 

次に、別のバックトレースを実行して、実際の位置を把握します。

コンパイラによってARM用に使用される呼び出し規約を理解できる場合は、同様のことができるはずです。