前: Bug Criteria, 上: GDB Bugs
いくつかの企業や個人がgnuのソフトウェアをサポートしています。 こうしたサポート組織からGDBを入手したのであれば、 まずその組織に連絡することをお勧めします。
サポートを提供している多くの企業、 個人の連絡先情報が、 gnu Emacsディストリビューションのetc/SERVICEファイルに記載されています。
どのような場合でも、 GDBのバグ報告を (英語で) 以下のアドレスに送ることをお勧めします。 1
bug-gdb@prep.ai.mit.edu
`info-gdb'、 `help-gdb'、 および、 いかなるニュースグループにもバグ報告を送ることはしないでください。 GDBユーザのほとんどは、 バグ報告を受け取りたいと考えてはいません。 バグ報告を受け取りたいと思っている人は、 `bug-gdb'の配信を受けるようにしているはずです。
メーリング・リスト`bug-gdb'には、 リピータとして機能する`gnu.gdb.bug'というニュースグループがあります。 このメーリング・リストとニュースグループは、 全く同一のメッセージを配信しています。 メーリング・リストではなくニュースグループにバグ報告を流そうと考える人がよくいます。 これはうまく機能するように見えますが、 1つ重大な問題があります。 ニュースグループへの投稿では、 送信者へのメール・パスが分からないことがよくあります。 したがって、 もっと多くの情報が必要になったときに、 バグの報告者と連絡を取ることができない可能性があります。 こういうことがあるので、 メーリング・リストへのバグ報告の方が望ましいのです。
最後の手段として、 バグ報告を(英語で)紙に書いて下記に郵送するという方法があります。
gnu Debugger Bugs
Free Software Foundation Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307
USA
役に立つバグ報告を行うための最も根本的な原則は、 すべての事実を報告することです。 ある事実を書くべきか省くべきかよく分からない場合は、 書くようにしてください。
事実が省略されてしまうことがよくありますが、 これはバグ報告者が、 自分には問題の原因は既に分かっていると考え、 いくつかの細かい点は関係がないと仮定してしまうからです。 したがって、 例の中で使った変数の名前などは重要ではないと、 報告者は考えます。 おそらくそうかもしれません。 しかし、 完全にそうであるとも言い切れません。 メモリの参照がデタラメな場所を指しているというバグで、 それがたまたまメモリ上においてその名前が置かれている箇所から値を取り出しているということがあるかもしれません。 名前が異なれば、 そこの内容は、 バグが存在するにもかかわらずデバッガが正しく動作してしまうような値になるかもしれません。 このようなことがないよう、 特定の完全な実例を提供してください。 バグの報告者にとっては、 このようにするのが最も簡単なはずであり、 かつ、 それが最も役に立つのです。
バグ報告の目的は、 そのバグを修正することができるようにすることにある、 という点を頭に入れておいてください。 そのバグが、 以前に報告されたものと同じであるという可能性もありますが、 バグ報告が完全なもので、 必要な情報がすべて含まれたものでなければ、 バグの報告者にも私たちにもそのことを知ることができません。
ときどき、 2、3の大雑把な事実だけを記述して、 「何か思い当たることはありますか?」と聞いてくる人がいます。 このようなバグ報告は役に立ちません。 このような報告には、 より適切なバグ報告を送るよう報告者に注意する場合を除いて、 返事をすることを拒否するよう強くお願いします。
バグを修正できるようにするためには、 報告者は以下の情報をすべて含めるべきです。
show version
コマンドで表示させることができます。
この情報がないと、 カレント・バージョンのGDBを使ってバグを探すことに意味があるのかどうかを知ることができません。
gcc --version
によってこの情報を知ることができます。
他のコンパイラについては、
そのドキュメントを参照してください。
make
からの出力)
を添付すれば十分でしょう。
引数が何であったのかを私たちが推測しようとしても、 おそらく誤った推測をしてしまうでしょう。 そうなると、 バグは再現しないかもしれません。
もちろん、 GDBが致命的なシグナルを受信するというバグであれば、 私たちも間違いなくそれに気がつくでしょう。 しかし、 出力が正しくないというバグであれば、 紛れもない誤りでなければ、 私たちはそれに気付かないかもしれません。 私たちが間違いをする可能性を排除するようにしてください。
たとえ致命的なシグナルを受信するような問題であっても、 報告者はそのことを明示的に報告するべきです。 何か奇妙なことが起こっていると仮定しましょう。 例えば、 報告者が使っているGDBにちぐはぐなところがあるとか、 報告者のシステム上にあるCライブラリのバグだった、 というような場合です (こういうことは、 実際にありました!)。 このような場合、 報告者のGDBはクラッシュしても、 私たちのところではクラッシュしません。 クラッシュするはずであると報告されていれば、 私たちのGDBがクラッシュしなくても、 「私たちのところではバグが発生しない」ということを知ることができます。 クラッシュするはずであるという報告がなければ、 実際の現象から何も結論を引き出すことができません。
私たちが開発中のソースの行番号は、 報告者の持っているソースの行番号とは一致しないでしょう。 報告者から見たソースの行番号は、 私たちにとって役に立つ情報を提供してくれません。
以下に、 バグ報告に必要ではない情報をいくつか列挙します。
バグを見つけると、 多くの時間をかけて、 入力ファイルをどのように変更するとバグが発生しなくなり、 どのように変更した場合はバグが発生し続けるかを調べる人がよくいます。
これは多くの場合、 時間のかかる作業であり、 しかもあまり役に立ちません。 というのは、 私たちがバグを見つけるのは、 デバッガでブレイクポイントを使いながら1つの実例を実行させることによってであり、 一連の実例からの純粋な演繹によってではないからです。 時間を無駄にせず、 何かほかのことに使うようお勧めします。
もちろん、 一番最初にバグを見つけたときの実例の代わりとなる、 もっと単純な実例を見つけることができるのであれば、 私たちにとっても便利です。 出力におけるエラーはより発見しやすいものですし、 デバッガ配下で実行させる方が時間がかかりません。
しかし、 単純化は絶対に必要というわけでもありません。 こういうことをしたくないのであれば、 バグを発見したときのテスト・ケース全体を送って、 バグの報告を行ってください。
バグに対するパッチは、 それが良いものであれば、 役に立ちます。 しかし、 パッチがあれば十分であるとみなして、 テスト・ケースのような必要な情報を送るのを省かないでください。 提供されたパッチに問題があり、 別の方法で問題を修正することにする場合もありますし、 提供されたパッチを全く理解できないということもあるかもしれません。
GDBのような複雑なプログラムでは、 コード中のある特定のパスを通るような実例を作成するのは困難なことがあります。 報告者が実例を送ってくれなければ、 私たちには実例を作成することができず、 したがって、 バグが修正されたことを検証することができなくなってしまいます。
また、 報告者の送ってくれたパッチがどのような問題を修正しようとしているのか私たちに理解できない場合、 あるいは、 なぜそのパッチが改善になるのか私たちが理解できない場合、 そのパッチを組み込むことはしません。 テスト・ケースが1つでもあれば、 そうしたことを理解するのに役立つでしょう。
このような推測は普通は間違っているものです。 私たちですら、 デバッガを使って事実を見出すまでは、 このような点に関して正しく推測することはできないのです。