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