人々はよく，問題を発生させるものを知っていて，重要でない詳細もあると思うため，事実を省略します．このため，使用したファイル名は重要でないと考えたとします．さて，おそらくそうでしょうが，確実ではありません．おそらくバグは，パス名がメモリに保存されている場所から取り出すために生じる，偶然のメモリ参照です．おそらく，パス名が異なっている場合，その場所の内容は，バグにもかかわらず正しいことを行うユーティリティを馬鹿にするでしょう．安全に動作するようにし，特定の完全な例を与えてください．それは，最も簡単に行うことができ，最も役に立ちます．

バグの報告の目的が，新しいものの場合は，バグの修正を可能にすることだということを覚えておいてください．そのため，以前にバグが報告されていないことを常に前提にして，バグの報告を書いてください．

ときどき，概略だけのわずかな事実を与え，"これは報告すべきですか？ (Does this ring a bell?)"と尋ねる人がいます．これでは，我々のバグの修正の助けにならないので，基本的には役に立ちません．我々は，調査することが可能になるように十分に詳細な内容を尋ねる返事を出します．またまた最初から，問題を早急に送るはめになるでしょう．

バグの修正を可能とするため，以下のすべてのものを含めるべきです．

ユーティリティのバージョン．それぞれのバージョンは，`--version' 引数を用いて開始した場合，それを報告します．
これがなければ，我々はバイナリユーティリティの現在のバージョンにバグを探す場所があるかどうか分かりません．
BFDライブラリを作るために与えたパッチを含む，ソースに適用したあらゆるパッチ．
使用しているマシンの形式と，オペレーティングシステム名とバージョンナンバー．
ユーティリティをコンパイルするとき使用したコンパイラ(とバージョン) --- 例えば，"gcc-2.7"．
バグを観測するためにユーティリティに与えたコマンド引数．重要なものを省略しないことを保証するため，すべてをリストアップしてください． Makefile(またはmakeの出力)のコピーで十分です．
我々が引数を推測しようとした場合，おそらく間違ったものを推測し，バグに遭遇しない可能性があります．
完全な入力ファイルまたは入力ファイルの組で，実際のオブジェクトファイルを送ることは，最も役に立ち，バグがあればuuencodeしてください．ユーティリティがオブジェクトファイルやファイルを読み込んでいる場合，それをメールシステムに通過させる場合必要です．`[email protected]'はメーリングリストなので，非常に大きなファイルをそこに送ることは避けるよう注意してください．ファイルをanonymous FTPで利用可能にするとOKです．
ソースファイルがGNUプログラム(例えば，gcc， gas，そして/または，GNU ld)を使用して生成されたことが明らかな場合，オブジェクトファイルよりソースファイルを送ることでOKです．この場合，gccや，それらオブジェクトファイルを生成するために使用したあらゆるもののバージョンを正確に確実に伝えてください． gccや，それらあらゆるもののコンフィグレーションの方法も伝えてください．
適当でないと確信することになった動作の記述．例えば，"致命的なシグナルを得た"．
もちろん，バグはユーティリティが致命的なシグナルを得た場合，我々はきっとそこに注目します．しかし，バグが不適切な出力の場合，我々は，明らかに間違っていない限り注目しないかもしれません．我々が間違う機会を与えない方がよいでしょう．

遭遇した問題が致命的なシグナルの場合でさえ，それを明確に伝えるべきです．ユーティリティのコピーが同期化されていない，または，システムのCライブラリのバグに遭遇したといった，おそらく何か変なことが生じています．(それは発生したのです！) コピーは壊れていて，我々のはそうでないかもしれません．壊れることを期待していると我々に告げ，我々が壊すことに失敗した場合，我々にバグは発生しないことを知るでしょう．壊れることを期待していると我々に告げない場合，我々は自分達の観測から全く結論が得られないでしょう．
ソースの変更を提案したい場合，`-u'，`-c'，または `-p'オプションを用いたdiffで生成したような，コンテクストのdiffを我々に送ってください．古いファイルから新しいファイルへのdiff を，常に送ってください．ldのソースについて何か議論したい場合，行番号ではなくコンテクストで参照してください．
我々の開発ソース内の行番号は，あなた方のソースと一致しないでしょう．行番号は我々に全く情報をもたらしません．

不要なものは以下のものです．

バグの回りの説明．
バグに遭遇した人は，バグを無くす入力ファイルへの変更と，効果がない変更を調査するのに多くの時間を費やすことが多いです．

我々がバグを見つける方法は，単純な例をブレークポイントを用いたデバッガで実行することで，それは一連の例から推測することではないので，これは役に立たないことが多いです．我々は，他のことをすることを勧めます．

もちろん，報告するためのオリジナルの例ではなく，それより簡単な例が見つかった場合，それはとても役立ちます．出力ファイルのエラーは，見つけるのがより簡単，デバッガの実行に余り時間がかからない，等々です．

しかし，簡略化は重要ではありません．こうしたくない場合，いい加減にバグを報告し，使用したテストケースを全て我々に送ってください．
バグに対するパッチ．
バグに対するパッチは，それが良いものであれば我々は助かります．しかし，テストケースのような，我々全員がパッチを必要だと推測するのに必要な情報を省略しないでください．我々は，パッチに関する問題が分かり，別の方法で問題を修正することに決めるかもしれませんし，全く理解できないかもしれません．

バイナリユーティリティと同じくらい複雑なプログラムを用いた場合，コードを通じて，プログラムに特定の手順をたどらせる例を構成することは，とても難しいことです．例を我々に送らない場合，我々はそれを構成することができないので，我々はバグが修正されたかどうか検証することができません．

そして，あなたが修正しようとしたバグや，パッチの改良点を我々が理解できない場合や，我々はそれをインストールしないでしょう．テストケースは我々の理解を助けます．
バグやそれが依存するものに関する推測．
そのような推測は，通常正しくありません．事実を見つけるために最初にデバッガを使用しなければ，我々でも正しく推測できません．

[ << ]

[ >> ]

[表紙]

[目次]

[索引]

[検索] [上端 / 下端] [?]