運転時デバッグ-デッドサイクルについて

2342 ワード

実行中のプログラムに対しては、gdb atch機能を使用して運転時のデバッグ(gdbを起動した後にatchコマンドを使用したり、gdbを起動する時に-pパラメータを使用します).
以下は故意に作られた簡単なデッドサイクルプログラムです.

#include <stdio.h>
#include <unistd.h>
int main()
{
    int i;
    for (i = 0; ; ++i) {
        printf("%d
", i);
        sleep(1);
    }
}

gcc-O 2コンパイルを使ってプログラムを実行し、別の仮想端末でgdb atchプロセスを使用します.

root@bt:～# gdb -q -p 2569
Attaching to process 2569
Reading symbols from /root/test3...(no debugging symbols found)...done.
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007fbf605ac380 in nanosleep () from /lib/libc.so.6
(gdb) bt
#0 0x00007fbf605ac380 in nanosleep () from /lib/libc.so.6
#1 0x00007fbf605ac210 in sleep () from /lib/libc.so.6
#2 0x00000000004005c8 in main ()
(gdb) finish
Run till exit from #0 0x00007fbf605ac380 in nanosleep () from /lib/libc.so.6
0x00007fbf605ac210 in sleep () from /lib/libc.so.6
(gdb) finish
Run till exit from #0 0x00007fbf605ac210 in sleep () from /lib/libc.so.6
0x00000000004005c8 in main ()
(gdb) ni
0x00000000004005a8 in main ()
(gdb)
0x00000000004005aa in main ()
(gdb)
0x00000000004005af in main ()
(gdb)
0x00000000004005b4 in main ()
(gdb)
0x00000000004005b6 in main ()
(gdb)
0x00000000004005b9 in main ()
(gdb)
0x00000000004005be in main ()
(gdb)
0x00000000004005c3 in main ()
(gdb)
0x00000000004005c8 in main ()
(gdb)
0x00000000004005a8 in main ()
(gdb)
0x00000000004005aa in main ()
...

atchはプロセスをハングアップします.現象は一時的なブレークポイントを挿入したようです.上の操作では、finishコマンドを2回使用してプログラムをmain関数に戻します.
-O 2オプションを使ってコンパイルしたプログラムでは、ソースコードレベルのデバッグは簡単に行えません.next/stepコマンドは利用できません.このようなプログラムに対して、nexti/stepコマンドが使用されてもよく、それらは概してnext/stepと同じで、それぞれステップオーバーとステップを表しています.違いは前者が単一のアセンブリ命令に対していることです.上記の例では、ニ(nexti)コマンドが連続して使用されており、コマンドアドレス(ripレジスタ値)から、デッドサイクルが発見されやすく、コマンドアドレスは常に0 x 000004005 a 8-0 x 00004008 c 8を徘徊している.
この技はバックグラウンドのdaemenプログラムにかなり効果的です.私は保護プロセスを持ったdeamonプログラムを維持したことがあります.問題が発生した中性子プロセスに対して、保護プロセスはそれを殺して再起動しますが、詳しい原因は記録されません.一日、あるバージョンは頻繁に再起動し、指導者は死の命令を下しました.XXXの前に解決しなければなりません.重量級の上古神器gdbを使って保護過程を掛けて、中性子を運行する過程を自然消滅させます.日の可哀相に会って、やっと一週間後に問題を再現しました.上記の方法を使って死循環問題と位置を確認しました.
あの夜、花の群れを見ました.

WindowsプラットフォームMinGW GCCはコンパイルしてC++Boostを使用します.

22.凸凹スタンプ