Go to the first, previous, next, last section, table of contents.
バグの報告は,バイナリユーティリティを確実にする上で重要な役割を果たしま
す.
バグを報告することで,問題の解決をもたらすかもしれませんが,そうでないか
もしれません.しかし,いずれにせよ,バグの報告の主な機能は,バイナリユー
ティリティの次のバージョンの仕事をより良くすることで,全てのコミュニティ
に役立つことです.バグの報告は,管理者に対する貢献になります.
バグの報告を目的に役立つようにするため,バグの修正が可能となるような情報
を含める必要があります.
バグを見つけたかどうか確実でない場合,ここに指針がいくつかあります.
-
バイナリユーティリティが,入力によらず,致命的なシグナルを得た場合,それ
はバグです.信頼できるユーティリティは決して壊れません.
-
バイナリユーティリティが有効な入力に対しエラーメッセージを生成した場合,
それはバグです.
-
バイナリユーティリティの経験豊かなユーザの場合,改良のための提案はいつで
も歓迎します.
多くの企業と個人が,GNU製品に対してサポートを提供しています.サポー
ト組織からバイナリユーティリティを得ている場合,われわれは,その組織に最
初に連絡するように勧めます.
GNU Emacs配布物のファイル`etc/SERVICE'で,サポートしている多く
の会社と個人へ連絡する情報を見つけることが可能です.
いずれにせよ,我々は,バイナリユーティリティに対するバグの報告を
`bug-binutils@gnu.org'にも送ることを勧めます.
バグの報告の有効な基本原理は以下のとおりです.すべての事実を報告
する.事実を述べるべきか削除すべきかよく分からない場合,それを述べてく
ださい!
人々はよく,問題を発生させるものを知っていて,重要でない詳細もあると思う
ため,事実を省略します.このため,使用したファイル名は重要でないと考えた
とします.さて,おそらくそうでしょうが,確実ではありません.おそらくバグ
は,パス名がメモリに保存されている場所から取り出すために生じる,偶然のメ
モリ参照です.おそらく,パス名が異なっている場合,その場所の内容は,バグ
にもかかわらず正しいことを行うユーティリティを馬鹿にするでしょう.安全に
動作するようにし,特定の完全な例を与えてください.それは,最も簡単に行う
ことができ,最も役に立ちます.
バグの報告の目的が,新しいものの場合は,バグの修正を可能にすることだとい
うことを覚えておいてください.そのため,以前にバグが報告されていないこと
を常に前提にして,バグの報告を書いてください.
ときどき,概略だけのわずかな事実を与え,"これは報告すべきですか? (Does
this ring a bell?)と尋ねる人がいます.これらのバグの報告は役に立たず,正
しくバグの報告をするよう送付者に小言を言うために,それに対する返答
を廃棄するようにということを,我々は全員に勧めます.
バグの修正を可能とするため,これらすべてのものを含めるべきです.
-
ユーティリティのバージョン.それぞれのバージョンは,@option{--version}引
数を用いて開始した場合,それを報告します.
これがなければ,我々はバイナリユーティリティの現在のバージョンにバグを探
す場所があるかどうか分かりません.
-
BFD
ライブラリを作るために与えたパッチを含む,ソースに適用したあら
ゆるパッチ.
-
使用しているマシンの形式と,オペレーティングシステム名とバージョンナン
バー.
-
ユーティリティをコンパイルするとき使用したコンパイラ(とバージョン) --
例えば,"
gcc-2.7
".
-
バグを観測するためにユーティリティに与えたコマンド引数.重要なものを省略
しないことを保証するため,すべてをリストアップしてください.Makefile(ま
たはmakeの出力)のコピーで十分です.
我々が引数を推測しようとした場合,おそらく間違ったものを推測し,バグに遭
遇しない可能性があります.
-
完全な入力ファイルまたは入力ファイルの組で,実際のオブジェクトファイルを
送ることは,最も役に立ち,バグがあればuuencodeしてください.ユーティリティ
がオブジェクトファイルやファイルを読み込んでいる場合,それをメールシステ
ムに通過させる場合必要です.`bug-binutils@gnu.org'はメーリングリス
トなので,非常に大きなファイルをそこに送ることは避けるよう注意してくださ
い.ファイルをanonymous FTPで利用可能にするとOKです.
ソースファイルがGNUプログラム(例えば,@command{gcc},@command{gas},
そして/または,GNU @command{ld})を使用して生成されたことが明らかな
場合,オブジェクトファイルよりソースファイルを送ることでOKです.この場合,
@command{gcc}や,それらオブジェクトファイルを生成するために使用したあら
ゆるもののバージョンを正確に確実に伝えてください.@command{gcc}や,それ
らあらゆるもののコンフィグレーションの方法も伝えてください.
-
適当でないと確信することになった動作の記述.例えば,"致命的なシグナルを
得た".
もちろん,バグはユーティリティが致命的なシグナルを得た場合,我々はきっと
そこに注目します.しかし,バグが不適切な出力の場合,我々は,明らかに間違っ
ていない限り注目しないかもしれません.我々が間違う機会を与えない方がよい
でしょう.
遭遇した問題が致命的なシグナルの場合でさえ,それを明確に伝えるべきです.
ユーティリティのコピーが同期化されていない,または,システムのCライブラ
リのバグに遭遇したといった,おそらく何か変なことが生じています.(それは
発生したのです!) コピーは壊れていて,我々のはそうでないかもしれません.
壊れることを期待していると我々に告げ,我々が壊すことに失敗した場合,我々
にバグは発生しないことを知るでしょう.壊れることを期待していると我々に告
げない場合,我々は自分達の観測から全く結論が得られないでしょう.
-
ソースの変更を提案したい場合,@option{-u},@option{-c},または
@option{-p}オプションを用いた@command{diff}で生成したような,コンテクス
トのdiffを我々に送ってください.古いファイルから新しいファイルへのdiffを,
常に送ってください.@command{ld}のソースについて何か議論したい場合,行番
号ではなくコンテクストで参照してください.
我々の開発ソース内の行番号は,あなた方のソースと一致しないでしょう.行番
号は我々に全く情報をもたらしません.
不要なものは以下のものです.
-
バグの回りの説明.
バグに遭遇した人は,バグを無くす入力ファイルへの変更と,効果がない変更を
調査するのに多くの時間を費やすことが多いです.
我々がバグを見つける方法は,単純な例をブレークポイントを用いたデバッガで
実行することで,それは一連の例から推測することではないので,これは役に立
たないことが多いです.我々は,他のことをすることを勧めます.
もちろん,報告するためのオリジナルの例ではなく,それより簡単な例
が見つかった場合,それはとても役立ちます.出力ファイルのエラーは,見つけ
るのがより簡単,デバッガの実行に余り時間がかからない,等々です.
しかし,簡略化は重要ではありません.こうしたくない場合,いい加減にバグを
報告し,使用したテストケースを全て我々に送ってください.
-
バグに対するパッチ.
バグに対するパッチは,それが良いものであれば我々は助かります.しかし,テ
ストケースのような,我々全員がパッチを必要だと推測するのに必要な情報を省
略しないでください.我々は,パッチに関する問題が分かり,別の方法で問題を
修正することに決めるかもしれませんし,全く理解できないかもしれません.
バイナリユーティリティと同じくらい複雑なプログラムを用いた場合,コードを
通じて,プログラムに特定の手順をたどらせる例を構成することは,とても難し
いことです.例を我々に送らない場合,我々はそれを構成することができないの
で,我々はバグが修正されたかどうか検証することができません.
そして,あなたが修正しようとしたバグや,パッチの改良点を我々が理解できな
い場合や,我々はそれをインストールしないでしょう.テストケースは我々の理
解を助けます.
-
バグやそれが依存するものに関する推測.
そのような推測は,通常正しくありません.事実を見つけるために最初にデバッ
ガを使用しなければ,我々でも正しく推測できません.
Go to the first, previous, next, last section, table of contents.