Previous: Bug Criteria, Up: GDB Bugs


17.2 バグの報告方法

いくつかの企業や個人が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の大雑把な事実だけを記述して、 「何か思い当たることはありますか?」と聞いてくる人がいます。 このようなバグ報告は役に立ちません。 このような報告には、 より適切なバグ報告を送るよう報告者に注意する場合を除いて、 返事をすることを拒否するよう強くお願いします。

バグを修正できるようにするためには、 報告者は以下の情報をすべて含めるべきです。

以下に、 バグ報告に必要ではない情報をいくつか列挙します。


脚注

[1] 訳注:この日本語の翻訳マニュアルのバグは、 日本語(か英語)で、 ki@home.email.ne.jpに報告してください。