16. バグの報告

バグの報告は，バイナリユーティリティを確実にする上で重要な役割を果たし ます．

バグを報告することで，問題の解決をもたらすかもしれませんが，そうでない かもしれません．しかし，いずれにせよ，バグの報告の主な機能は，バイナリ ユーティリティの次のバージョンの仕事をより良くすることで，全てのコミュ ニティに役立つことです．バグの報告は，管理者に対する貢献になります．

バグの報告を目的に役立つようにするため，バグの修正が可能となるような情 報を含める必要があります．

16.1 バグを見つけましたか？

バグを見つけたかどうか確実でない場合，ここに指針がいくつかあります．

• バイナリユーティリティが，入力によらず，致命的なシグナルを得た場合，そ れはバグです．信頼できるユーティリティは決して壊れません．

• バイナリユーティリティが有効な入力に対しエラーメッセージを生成した場合， それはバグです．

• バイナリユーティリティの経験豊かなユーザの場合，改良のための提案はいつ でも歓迎します．

16.2 バグの報告の方法

多くの企業と個人が，GNU製品に対してサポートを提供しています．サポー ト組織からバイナリユーティリティを得ている場合，われわれは，その組織に 最初に連絡するように勧めます．

GNU Emacs配布物のファイル`etc/SERVICE'で，サポートしている多 くの会社と個人へ連絡する情報を見つけることが可能です．

いずれにせよ，我々は，バイナリユーティリティに対するバグの報告を `bug-binutils@gnu.org'にも送ることを勧めます．

バグの報告の有効な基本原理は以下のとおりです．すべての事実を報 告する．事実を述べるべきか削除すべきかよく分からない場合，それを述べ てください！

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

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

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

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

• ユーティリティのバージョン．それぞれのバージョンは，`--version' 引数を用いて開始した場合，それを報告します．

  これがなければ，我々はバイナリユーティリティの現在のバージョンにバグを 探す場所があるかどうか分かりません．

• BFDライブラリを作るために与えたパッチを含む，ソースに適用したあ らゆるパッチ．

• 使用しているマシンの形式と，オペレーティングシステム名とバージョンナン バー．

• ユーティリティをコンパイルするとき使用したコンパイラ(とバージョン) -- 例えば，"gcc-2.7"．

• バグを観測するためにユーティリティに与えたコマンド引数．重要なものを省 略しないことを保証するため，すべてをリストアップしてください． Makefile(またはmakeの出力)のコピーで十分です．

  我々が引数を推測しようとした場合，おそらく間違ったものを推測し，バグに 遭遇しない可能性があります．

• 完全な入力ファイルまたは入力ファイルの組で，実際のオブジェクトファイル を送ることは，最も役に立ち，バグがあればuuencodeしてください．ユーティ リティがオブジェクトファイルやファイルを読み込んでいる場合，それをメー ルシステムに通過させる場合必要です．`bug-binutils@gnu.org'はメー リングリストなので，非常に大きなファイルをそこに送ることは避けるよう注 意してください．ファイルをanonymous FTPで利用可能にするとOKです．

  ソースファイルがGNUプログラム(例えば，gcc， gas，そして/または，GNU ld)を使用して生成され たことが明らかな場合，オブジェクトファイルよりソースファイルを送ること でOKです．この場合，gccや，それらオブジェクトファイルを生成 するために使用したあらゆるもののバージョンを正確に確実に伝えてください． gccや，それらあらゆるもののコンフィグレーションの方法も伝え てください．

• 適当でないと確信することになった動作の記述．例えば，"致命的なシグナル を得た"．

  もちろん，バグはユーティリティが致命的なシグナルを得た場合，我々はきっ とそこに注目します．しかし，バグが不適切な出力の場合，我々は，明らかに 間違っていない限り注目しないかもしれません．我々が間違う機会を与えない 方がよいでしょう．

  遭遇した問題が致命的なシグナルの場合でさえ，それを明確に伝えるべきです． ユーティリティのコピーが同期化されていない，または，システムのCライブ ラリのバグに遭遇したといった，おそらく何か変なことが生じています．(そ れは発生したのです！) コピーは壊れていて，我々のはそうでないかもしれま せん．壊れることを期待していると我々に告げ，我々が壊すことに失敗した場 合，我々にバグは発生しないことを知るでしょう．壊れることを期待している と我々に告げない場合，我々は自分達の観測から全く結論が得られないでしょ う．

• ソースの変更を提案したい場合，`-u'，`-c'，または `-p'オプションを用いたdiffで生成したような，コンテク ストのdiffを我々に送ってください．古いファイルから新しいファイルへの diffを，常に送ってください．ldのソースについて何か議論したい 場合，行番号ではなくコンテクストで参照してください．

  我々の開発ソース内の行番号は，あなた方のソースと一致しないでしょう．行 番号は我々に全く情報をもたらしません．

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

• バグの回りの説明．

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

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

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

  しかし，簡略化は重要ではありません．こうしたくない場合，いい加減にバグ を報告し，使用したテストケースを全て我々に送ってください．

• バグに対するパッチ．

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

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

  そして，あなたが修正しようとしたバグや，パッチの改良点を我々が理解でき ない場合や，我々はそれをインストールしないでしょう．テストケースは我々 の理解を助けます．

• バグやそれが依存するものに関する推測．

  そのような推測は，通常正しくありません．事実を見つけるために最初にデバッ ガを使用しなければ，我々でも正しく推測できません．