スレッドに関する2つの質問

Question

1. gdbコアにライブラリがない/壊れている場合、どうすればそれを分離できますか？

2. スレッドが独自のスタックを上書きしている可能性があることも読んでいますが、どのように検出できますか？

どのように上記の問題を以下のbtと分離するのですか？

/etc/gdb/gdbinit:105: Error in sourced command file: 
Error while executing Python code. 
Reading symbols from /opt/hsp/bin/addrman...done. 

warning: Corrupted shared library list: 0x0 != 0x7c8d48ea8948c089 

warning: Corrupted shared library list: 0x0 != 0x4ed700 

warning: no loadable sections found in added symbol-file system-supplied DSO at 
0x7ffd50ff6000 
Core was generated by `addrman --notification-socket 
/opt/hsp/sockets/memb_notify.socket'. 
Program terminated with signal 11, Segmentation fault. 
#0 0x00000000004759e4 in ps_locktrk_info::lktrk_locker_set (this=0x348, 
locker_ip=<optimized out>) at ./ps/ps_lock_track.h:292 
292  ./ps/ps_lock_track.h: No such file or directory. 
(gdb) bt 
#0 0x00000000004759e4 in ps_locktrk_info::lktrk_locker_set (this=0x348, 
locker_ip=<optimized out>) at ./ps/ps_lock_track.h:292 
#1 0x0000000000000000 in ??() 

Answer 1

コアファイルが破損している可能性があります。ヒープやスタックの破損が原因である可能性があります。破損は、しばしばバッファオーバーフローまたは未定義の動作の結果です。

Linuxで実行している場合は、valgrindを試してみましょう。それはしばしば腐敗を非常に迅速に見つけ出すことができます。 Windowsには同様のツールがあります。

はい、マルチスレッドアプリケーションはスタックをオーバーフローさせる可能性があります。各スレッドは、限られた量だけ割り当てられます。これは通常、非常に深い関数呼び出しスタックを持っているか、大きなローカルオブジェクトをスタックに割り当てている場合にのみ発生します。

Linuxアプリケーションのスタックサイズの設定については、hereとhereという興味深い情報があります。あなたの問題に直面して

、私はなります

1. はlktrk_loce​​r_setメソッドのすべての呼び出し元を確認してください。可能であれば問題
2. が発行し

Answer 2

を隔離するためにデバッグログを追加発見するValgrindのまたは同様のツールを使用してみてください明白なスタックオーバーフローやヒープ破損

があるかどうかを確認するために、それぞれを慎重に調査しますwarning: Corrupted shared library list: 0x0 != 0x7c8d48ea8948c089

上記のエラーは、通常は、コア・ダンプを生成したときに使用されるものの中からGDB異なるシステム・ライブラリ（またはメインバイナリ）を得た記号です。

開発マシン上で "本番"のコアダンプを分析しているか、コアダンプが作成された時点と分析中の時点、またはメインのバイナリを再構築した時点の間にシステムライブラリをアップグレードしたかのいずれかです。

this answerを参照してください。上記のいずれかが正しい場合はどうすればよいですか。