[Contents] [Back] [Prev] [Up] [Next] [Forward]
ユーザからのバグ報告は、
GDBの信頼性を向上させるのに重要な役割を果たしています。
バグを報告することで、
その問題の解決につながり、
結果として報告者自ら利益を得ることができるかもしれません。
もちろん、
何の解決にもつながらないこともあります。
しかし、
いずれにしても、
バグ報告の主要な意義は、
次のバージョンのGDBをより良いものにすることで、
コミュニティ全体の役に立つという点にあります。
バグ報告は、
GDBの保守作業へのユーザからの貢献です。
バグ報告がその目的とするところを首尾よく達成できるようにするためには、
バグを修正することを可能にするような情報が提供されなければなりません。
発見した現象がバグかどうかよく分からない場合には、
以下のガイドラインを参照してください。
-
入力された情報が何であれ、
デバッガが致命的なシグナルを受信するのであれば、
それはGDBのバグです。
信頼性のあるデバッガは決してクラッシュなどしません。
-
正当な入力に対してGDBがエラー・メッセージを出力するのであれば、
それはバグです。
(クロス・デバッグを行っている場合には、
ターゲットへの接続に問題がある可能性もあるということに注意してください。)
-
不正な入力に対してGDBがエラー・メッセージを出力しないのであれば、
それはバグです。
ただし、
ユーザにとって「不正な入力」に思えるものが、
実は「拡張機能」であったり
「古くから使われている用法のサポート」であったりすることもあります。
-
デバッグ・ツールに関する経験が豊富なユーザからのGDBの改善提案は、
どのような場合でも歓迎です。
(18)
いくつかの企業や個人がGNUのソフトウェアをサポートしています。
こうしたサポート組織からGDBを入手したのであれば、
まずその組織に連絡することをお勧めします。
サポートを提供している多くの企業、
個人の連絡先情報が、
GNU Emacsディストリビューションの`etc/SERVICE'ファイルに記載されています。
どのような場合でも、
GDBのバグ報告を
(英語で)
以下のアドレスに送ることをお勧めします。
(19)
bug-gdb@gnu.org
`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の大雑把な事実だけを記述して、
「何か思い当たることはありますか?」と聞いてくる人がいます。
このようなバグ報告は役に立ちません。
このような報告には、
より適切なバグ報告を送るよう報告者に注意する場合を除いて、
返事をすることを拒否するよう強くお願いします。
バグを修正できるようにするためには、
報告者は以下の情報をすべて含めるべきです。
-
GDBのバージョン。
GDBのバージョンは、
引数を指定せずにGDBを起動すると、
表示されます。
また、
いつでも
show version
コマンドで表示させることができます。
この情報がないと、
カレント・バージョンのGDBを使ってバグを探すことに意味があるのかどうかを知ることができません。
-
使っているマシンのタイプ、
オペレーティング・システムの名前とバージョン番号。
-
GDBをコンパイルするのに使われたコンパイラ
(および、
そのバージョン)。
例えば、
gcc--2.8.1。
-
デバッグ対象のプログラムをコンパイルするのに使われたコンパイラ
(および、
そのバージョン)。
例えば、
gcc--2.8.1、
あるいは、
HP92453-01 A.10.32.03 HP Cコンパイラ。
GCCについては、
gcc --version
によってこの情報を知ることができます。
他のコンパイラについては、
そのドキュメントを参照してください。
-
バグを見つけたプログラムをコンパイルする際に、
コンパイラに渡したコマンド引数。
例えば、
`-O'オプションを使ったか否かなど。
何か重要な点を省いてしまうことがないよう、
すべての引数を記述してください。
`Makefile'のコピー
(あるいは、
make
からの出力)
を添付すれば十分でしょう。
引数が何であったのかを私たちが推測しようとしても、
おそらく誤った推測をしてしまうでしょう。
そうなると、
バグは再現しないかもしれません。
-
バグを再現することのできる、
完全な入力スクリプトとすべての必要なソース・ファイル。
-
発見された、
正しくないと思われる動作の説明。
例えば、
「致命的なシグナルを受信する」など。
もちろん、
GDBが致命的なシグナルを受信するというバグであれば、
私たちも間違いなくそれに気がつくでしょう。
しかし、
出力が正しくないというバグであれば、
紛れもない誤りでなければ、
私たちはそれに気付かないかもしれません。
私たちが間違いをする可能性を排除するようにしてください。
たとえ致命的なシグナルを受信するような問題であっても、
報告者はそのことを明示的に報告するべきです。
何か奇妙なことが起こっていると仮定しましょう。
例えば、
報告者が使っているGDBにちぐはぐなところがあるとか、
報告者のシステム上にあるCライブラリのバグだった、
というような場合です
(こういうことは、
実際にありました!)。
このような場合、
報告者のGDBはクラッシュしても、
私たちのところではクラッシュしません。
クラッシュするはずであると報告されていれば、
私たちのGDBがクラッシュしなくても、
「私たちのところではバグが発生しない」ということを知ることができます。
クラッシュするはずであるという報告がなければ、
実際の現象から何も結論を引き出すことができません。
-
もしGDBのソースへの修正を提案したいのであれば、
コンテキスト付きの差分情報を送ってください。
GDBのソースについて何か議論する場合も、
行番号に言及するのではなく、
コンテキストに言及してください。
私たちが開発中のソースの行番号は、
報告者の持っているソースの行番号とは一致しないでしょう。
報告者から見たソースの行番号は、
私たちにとって役に立つ情報を提供してくれません。
以下に、
バグ報告に必要ではない情報をいくつか列挙します。
-
バグの包括的な説明。
バグを見つけると、
多くの時間をかけて、
入力ファイルをどのように変更するとバグが発生しなくなり、
どのように変更した場合はバグが発生し続けるかを調べる人がよくいます。
これは多くの場合、
時間のかかる作業であり、
しかもあまり役に立ちません。
というのは、
私たちがバグを見つけるのは、
デバッガでブレイクポイントを使いながら1つの実例を実行させることによってであり、
一連の実例からの純粋な演繹によってではないからです。
時間を無駄にせず、
何かほかのことに使うようお勧めします。
もちろん、
一番最初にバグを見つけたときの実例の代わりとなる、
もっと単純な実例を見つけることができるのであれば、
私たちにとっても便利です。
出力におけるエラーはより発見しやすいものですし、
デバッガ配下で実行させる方が時間がかかりません。
しかし、
単純化は絶対に必要というわけでもありません。
こういうことをしたくないのであれば、
バグを発見したときのテスト・ケース全体を送って、
バグの報告を行ってください。
-
バグに対するパッチ。
バグに対するパッチは、
それが良いものであれば、
役に立ちます。
しかし、
パッチがあれば十分であるとみなして、
テスト・ケースのような必要な情報を送るのを省かないでください。
提供されたパッチに問題があり、
別の方法で問題を修正することにする場合もありますし、
提供されたパッチを全く理解できないということもあるかもしれません。
GDBのような複雑なプログラムでは、
コード中のある特定のパスを通るような実例を作成するのは困難なことがあります。
報告者が実例を送ってくれなければ、
私たちには実例を作成することができず、
したがって、
バグが修正されたことを検証することができなくなってしまいます。
また、
報告者の送ってくれたパッチがどのような問題を修正しようとしているのか私たちに理解できない場合、
あるいは、
なぜそのパッチが改善になるのか私たちが理解できない場合、
そのパッチを組み込むことはしません。
テスト・ケースが1つでもあれば、
そうしたことを理解するのに役立つでしょう。
-
バグが何であるか、
あるいは、
何に依存しているかに関する推測。
このような推測は普通は間違っているものです。
私たちですら、
デバッガを使って事実を見出すまでは、
このような点に関して正しく推測することはできないのです。
[Contents] [Back] [Prev] [Up] [Next] [Forward]