0

powerpcプラットフォームのMontavistaLinuxで実行されているアプリケーションの1つがクラッシュしました。上位3つのスタックフレームには、シンボルではなく絶対アドレスが表示されます。私のビルドマシンは別のプラットフォームでホストされており、クロスコンパイラを使用してアプリケーションをビルドしています。どうすればシンボルを取り戻すことができますか。

バックトレースを以下に示します-

#0  0x0f272adc in ?? () from /lib/libc.so.6
#1  0x0f3537fc in ?? () from /lib/libc.so.6
#2  0x0f274f44 in ?? () from /lib/libc.so.6
#3  0x0f276e94 in malloc () from /lib/libc.so.6
#4  0x105c94a8 in fast_memget (module_id=0, noctets=820, err=0x3893e710) at ../common/src/portlayer.c:1305
#5  0x1055f734 in glbSipParserDecodeMessage (
    message=0x3b225e58 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 10.194.182.55:5060;branch=z9hG4bK2495419925-4086;received=10.194.182.55;ingress-zone=mxenode51\r\nCall-ID: 2469861343-4086\r\nCSeq: 6 INFO\r\nContact: <sip:4084565719@10.194"..., opt=0x3893e70c, messageLength=425, nextmesg=0x3893e898, pContext=0x3893e8cc, ppSipMessage=0x3893e6bc, err=0x3893e710) at src/sipdecode.c:6184
4

3 に答える 3

2

デバッグ情報を含む C ライブラリ (libc) をインストールする必要があります。Debian または派生システム (Ubuntu など) では、libc6-dbg.

于 2012-05-23T12:36:41.800 に答える
1

最後の 3 つのフレームには、どういうわけか有効な情報がありません。推測: おそらく malloc から呼び出されたいくつかのアセンブリ関数 (ただし、これらのフレームはおそらく読み取り可能である必要があります)。

しかし、同じライブラリから malloc のアドレスを知っているので、そのフレームの PC の相対的な差を計算できます (例: フレーム #2 の -1f50)。クロス ツールチェーンを使用し、objdump -d libc.so を実行して、malloc のコードを確認します - その違い...

于 2012-05-23T13:56:44.017 に答える
1

コメントの追加情報を考慮して、確認すべき点がいくつかあります。

アプリケーションは最適化 (-O1、-O2 など) を使用してコンパイルされましたか? その場合は、これらのオプションを指定せずに再コンパイルしてください。Cavium Octeon (MIPS) でクロスコンパイルしているときにこの状況に遭遇し、最適化フラグの存在がシンボルの表示に問題を引き起こしていることを確認しました。

スタックが何らかの形で破損している可能性がありますか? もしそうなら、私はすべてのフレームが壊れていると思います. Valgrind のようなものを使用して、踏んだ記憶がどこかにあるかどうかを確認する可能性はありますか? または、少なくとも Linux でアプリケーションを実行しますか?

先に進む前に、最初の 3 つのフレームについてさらに知る必要がありますか? mallocでクラッシュしたことを十分に知っていませんか？代わりに、malloc で何がクラッシュを引き起こす可能性があるかを検討する必要があります。前述の同じ Cavium プラットフォームで、メモリが残っていないときに malloc/new を呼び出すと、システムがクラッシュするという問題がありました:( バグを通知した後でも、ハッキーな回避策を使用する必要がありました。 malloc/new を呼び出すときに NULL をチェックしていますか? 複数の異なる場所から呼び出すと、これは困難になる可能性があります. new/malloc をラップしたので、これは簡単に実行できました.

OPからのコメントの後に更新

メモリリークが原因であるかどうかにかかわらず、メモリが不足してもクラッシュすることはありませんが、malloc が NULL を返さないことを確認してください。here で説明されているように、「メモリ不足ハンドラー」の使用も検討する必要があります。

その同じ Cavium プラットフォームで、追跡が非常に困難な同様のメモリ破損の問題がありました (まだ valgrind を使用して Linux で実行することはできませんでした)。malloc を実行するたびに、内部メモリ ヘッダーの有効性を確認する方法を見つけました。これにより速度が大幅に低下しましたが、最終的には問題を見つけることができました。このようなもの、または Linux の valgrind にアクセスできない場合は、malloc/new を「ラップ」して自分で実装することを検討できます。これは非常に複雑ですが、最悪のケースになる可能性があります。

于 2012-05-23T13:47:08.920 に答える