Tips for Productive Debugging with GDBの抄訳。 Tips 1: GDB Dashboardを使おう GDB Dashboardは単一の.gdbinitファイルで、ブレークポイントで止まるたびに下図のようなクールな画面を表示してくれる。 https://github.com/cyrus-and/gdb-dashboard gdbには標準でTUIモード（cursesベースのUI）が搭載されているが、そちらは画面の乱れが頻繁に起こる。GDB Dashboardはcursesを使っていないので乱れが起きない。 スクショではOutput/messages, Source, Assembly, Threadsなど多数のモジュールを全部入りで表示しているためゴチャゴチャしているが、設定で自分に必要なモジュールだけを表示するようにできる。 訳者もしばらく使っているが、
ソフトウェアがデッドロックや無限ループ等で応答しなくなったり、Segmentation Fault等で強制終了したりする場合での、gdbを使った解析手法について簡単なまとめ。 なお今回の内容はunixやlinux開発での基本知識となっていると思うけれど、例えば組み込みlinux開発などでは活用できるのを知らずに、printfデバッグで頑張っている所が結構あるようだ。開発が楽になるので基礎として知っておいて損はないと思う。 ソフトウェアが落ちる状態の解析 まず例外発生などでソフトウェアが異常終了する場合の解析について。 例えば以下のコードを実行すると、メモリアクセスエラーで異常終了する。 //main.c void hoge1(void) { int *hoge = (int *)0xDEADBEEF; hoge[0] = 100; } void hoge2(void) { hoge1();
前回までに、デバッガを使用する上での最低限のことを覚えました。 ステップ実行 変数の表示、変更 ブレークポイント 今回は少しレベルを上げて、よりデバッガを使いこなすためのコマンドを紹介します。 ウォッチポイント ウォッチポイントはブレークポイントに近いものですが、ブレークポイントのように「ある地点に遭遇したら停止」ではなく、「監視している変数を操作したら停止」という流れになります。 ファイル内から該当する変数名を探せばいいと考えるかもしれませんが、C言語ではポインタによる変数の別名を付けることが可能であるため、そう単純にはいきません。 書き込みの監視 あまりよいサンプルが思いつかなかったため、簡単で無意味な例を示します。 counter.c #include <stdio.h> void set_counter(int *); int count = 1; int watchee = 0;
C言語で実装されたライブラリやアプリケーションでは、汎用的な型として随所で void* が使用されますが、これをgdbからデバッグすると、そのままでは型情報が無いためタダのポインタとして扱われてしまいます。これではデバッグ時の都合がよろしくないです。 (gdb) print 0xfee65c0 $1 = 267281856 (gdb) print (void *)0xfee65c0 $2 = (void *) 0xfee65c0 こんなとき、この void* が指し示している先の型がわかりきっている場合は、その型でキャストしてやって: (gdb) print (struct imap_session_state_data *)0xfee65c0 $4 = (struct imap_session_state_data *) 0xfee65c0 (gdb) print $4 $5 = (st
たとえば、変数 var の値を2進数で表示したい場合は、次のように指定します。 (gdb) p/t var 一覧表示 whatis 変数の型を調べる。 info b 今設定しているブレークポイントの一覧を表示 セグメントフォルトをした後に利用すれば、どの関数で発生したか確認できます。 info stack 関数の呼び出しスタックの一覧を表示 info Thread 存在しているスレッドの一覧を表示 異なるアドレスにおける処理継続 以下のコマンドを使用することで、ユーザが選択したアドレスにおいて実行を継続させることができます jump linespec linespecで指定される行において、実行を再開 jump *address addressで指定されるアドレスにある命令から、実行を再開 アドレスが分かっている場合のメモリリーク出力 xはhexの意味です。 (gdb) p (char*)
Unix系コマンドラインユーザーのための、 gcc/g++/g77 による開発におけるデバッグ術を簡単に紹介します。 以下の内容は gcc 2.7.2.3 での動作は確認しています。 g++/g77 でも恐らくは通用すると思うのですが、 ひょっとすると異なる部分があるかもしれません。 筆者は g++/g77 の使用経験がないので、その場合は御容赦を願います。 実行前 キーワード「コンパイルオプション, -Wall, -O2, -O4」 まずは gcc にオプション opt'-Wall' を付けてコンパイルし、 警告がなくなるまでソースを修正します。 これは 常識 です。 次に opt'-O4 -Wall' でコンパイルします。 「未初期化変数の使用」の警告 (`foo' might be used uninitialized in this function) は、 opt'-O4' を付
しかし、ブレークポイントという機能はデバッガの手助けなしでは実現できません。 ブレークポイントとはプログラムの強制一時停止を行うポイントで、実行中のプログラムがブレークポイントに遭遇するとプログラムは一時停止され、デバッガによるプログラムへの介入を行えるようになります。 ブレークポイントは次のような場所に設定できます。 指定した行番号のプログラムを実行しようとする瞬間 関数を呼び出した瞬間 その他、C++などでは「例外が発生した瞬間」などにもブレークポイントを設定することができます。 行番号ブレーク ブレークポイントとしてよく使用されるのは、「プログラムの特定の位置」です。 例として、bubblesort.cプログラムのsort関数内で、隣り合う二つの要素を比較している箇所にブレークポイントを設定してみます。 25|/* bubble sort */ 26|void sort(int *a
RubyAdventJP, GC, Ruby（この記事はRuby Advent Calendar jp: 2009 : ATNDの4日目です。前日はmrknさんでした） 健全なるRubyistであれば、RubyのGCをいじることが週に一度はあるでしょう。そのときに困るのが、GCをいじってしまったことによるバグの修正です。GCをいじるというのは想像以上に難しく、少しでも書き間違えるとメモリ破壊が発生します。そのときに使えるTipsをこの記事で書くことにします。 みなさんご存じの通り、メモリ破壊というのは原因を特定するのが困難です。これは問題が発覚する場所とメモリ破壊が起こった現場が位置的に遠いことに起因しています。偉大なるハッカーのまつもとさんですら、その発見は困難です。 [ruby-dev:38628] Re: [BUG: trunk] called on terminated objec
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
