![[NetBSD Logo]](../../images/NetBSD-smaller.png)
NetBSD 問題報告
バグと問題報告システムの詳細
はじめに (トップ)
問題報告は、NetBSDを強靭で信頼性の高いシステムに作りあげるために 欠くことのできないものです。 我々は、バグ情報やオペレーティングシステムに足りない部分の報告を期待しています。
我々はせっかくの報告が無にならないようにGNATS データベースを用いてNetBSDの問題を追跡しています。 それぞれのNetBSDシステムにある send-pr(1) は、GNATSにバグレポートを提出するためのプログラムです。
NetBSD GNATS Databaseの検索・閲覧 (トップ)
GNATS databaseから問題報告を見るためには2つの方法があります。:
- データベースのサマリーで、 現在のすべての問題報告が種類ごとに並び替えられたページを見る。 これらのページは日に数回マスターデータベースサーバーからアップデートされます。
- 検索ページから検索する。
問題報告の提出 (トップ)
あなたが問題報告を提出する前に、その問題を GNATS データベースで検索するとよいでしょう。 だれかがすでに同じような問題を報告しているかもしれません (そして、すでに解決策もデータベースにあるかもしれません)。 また、バグと誤解されることのある機能の一覧も、 あわせて確認するとよいでしょう。
問題報告はぜひあなたのNetBSDシステムにある send-pr(1) プログラムで報告をしてください。このプログラムで送るフォームにはいくつかの 空欄があり、 そこにあなたの普段使用しているテキストエディタで情報を書き込んでください (なにを書いたらよいか分からない場合は、 アドバイスを読むとよいでしょう)。 書き上がったら send-pr(1) を用いて GNATS データベースに電子メールを送ってください。
問題報告がサーバーに到着すると書式チェックが自動的に行われ、 新しいPR番号が付与されてGNATS データベースに登録されます。 そして、カテゴリーの担当者に提出されたレポートが報告され、 そのコピーが netbsd-bugsメーリングリストに送られます。
さらに割り当てられたPR番号が報告の確認と共に、 あなた宛に送られます。 この番号は後にデータベースから報告を探すときに使われます。 問題報告にはバグとその解決策を追跡する上での広範囲な情報が含まれるため、 PR番号が有用になる場合があります。
既にある問題報告に追加する (トップ)
既に提出された報告に文章を追加する場合、
<gnats-bugs@NetBSD.org>
に電子メールを送ってください。
subjectは以下の例のように、
“Re: ” とカテゴリーと番号を記載してください。
Subject: Re: kern/5514
自動的にGNATSデータベースエントリーに追加され、 また、以下の各アドレス宛に自動的にカーボンコピーが送られます。
- 今回の電子メールを送った人
- その問題報告に関する “responsible” (担当者) として列挙されている人達
- その問題報告を最初に送った人
- “pkg” カテゴリーの問題報告の場合は、pkgsrc-bugs@NetBSD.org メーリングリスト
ここで、他の関心のある人達にカーボンコピーを送っておかないと、 その人達はあなたのメールのコピーを受け取らないことになるので注意してください。
問題報告の書き方 (トップ)
データベースが有用になるかどうかは、含まれるデータ次第です。 一般的に、ソフトウェアの問題を追跡したり解決したりするために、 どんな種類の情報が最も有用となるかは、常識 (そんなしろものがあるとして) で決まります。
- あなたが他人の報告を読む場合に必要とするであろう情報は、 すべて記入します。あなたの環境の詳細について毎回書く必要はありませんが、 他人の環境とは異なっているであろう部分 (たとえばパス) はすべて書いてください。
- 出来事をある程度絞って述べると、その情報は多くの場合、有用なものになります。 A が実行されてから B が実行され、そして C が実行されたことがバグに対処できる人にわかれば、 これらの事象のつながりが原因で失敗するような中間ステップを実現させうるとか、 余計なステップが原因で問題を顕在化させるような環境の変化を引き起こしうる、 ということがわかるかもしれません。 繰り返しますが、内容を絞ることは常に望ましいことですが (「構築を実行するようにしてから、コーヒー (コロンビア、クリーム入り、砂糖抜き) を取りに行き、シーラと電話で話したのちに、*この問題* は起きた…」)、 関連のある事項はすべて含めるようにしてください。
- Richard Stallman は次のように書いています。
これは、コンピューターソフトウェア・社会不正・オートバイの保守など、 あらゆる問題報告システムに通用することです。そしてこれは、一見些細な変化 (変数の変更、セミコロンが足りない、などなど) が大きな違いをもたらしうる ソフトウェア分野では、特に重要なことです。
有用なバグ報告の基本方針はこれだ: 事実をすべて報告する。 書くべきか書かざるべきか迷うのなら書きなさい!
- 各問題報告では、 ただひとつの問題を提出するようにしてください。 複数の問題があれば、問題報告を複数に分けてください。こうすることで、 各問題の追跡や、またそのプログラムに関連する問題の分析の助けとなります。
- 報告前に、そのバグがすでに報告されているかどうか、 ちょっと調べてみることは悪いことではありません。 ほとんどのソフトウェアでは、 既知のバグのリストが載ったリリースノートが附属しています。 さらに、あなたが遭遇した問題がすでに報告されているかどうか、 NetBSD GNATS 問題報告データベースを検索する のがよいでしょう (その問題を誰が知っているか? また、修正や回避策がデータベースにすでにあるかもしれません)。
- さらに、問題報告に限っていえば、データベース管理者が 報告された情報を適切に振り分けるために労力を使わなくていいように、 標準的な形式での報告が必要です。あらゆる人手や時間は、 問題の修正そのものに使われるべきであることを念頭に置いてください。 従って、もっとも重要なことは、報告の時点で、 問題報告に含まれる情報をできるかぎり正確に (フォーマットと内容のいずれも) 記述することです。より詳しくは、問題報告の 項目の説明 を参照してください。
カーネルがパニックし、十六進の数字がたくさん出て、停止したとします。 この現象の報告は重要です。 本物のオペレーティングシステムは、ハードウェアに重大な問題がない限り、 決してクラッシュやパニックを起こさないべきものだからです (ハードウェアの問題に対して OS ができることはほとんどありません)。 このほかパニックの原因となるものとしてはカーネルのバグがありますが、 NetBSD をさらに安定かつ強堅にするため、問題を追跡してバグをつぶす必要があります。
問題は、カーネルが出力するスタックダンプは、各カーネルに固有のもので あることです。そこで、この数字を実際のシンボルテーブルの参照に変換して、 あなたのシステムのカーネルを持っていない人が カーネルが死んだ時点の正確な状況がわかるようにする必要があります。
少なくとも、 "PC" の数値を書き写してシンボル参照に変換します - "PC" は、実行された時点のコンピューターの プログラムカウンター です; 理想的には、すべてをカット & ペーストできれば、 そうするほうが望ましいです。
カーネルが、以下のように出力したとします (たいていはこれが複数行あります):
pc = 0xf80ff430 args = (0x0, 0x41001fe5, 0xf8139c00, 0xf8123d20, 0xf8101e38, 0xf8143800, 0xf8123c68) fp = 0xf8123c68
PC の数値はカーネル毎に固有のもので、別のカーネルでは異なるものになります。 このため、シンボル参照に変換する必要があります。 十六進の PC 値をシンボル参照に変換するため、 以下のように gdb(1) を使います:
gdb -k /netbsd
x 0xf80ff430
0xf80ff430 <cpu_reboot+196>: 0x40000093
gdb(1) で得られたこの "<cpureboot+196>" が、 問題報告をもとに作業する人に必要ですので、これを (できれば残りの "args" 行も一緒に) 問題報告に含めてください。
カーネルパニックの徹底的な問題報告の例としては、 問題報告 #3765 を参照してください。
NetBSD問題報告の項目 (トップ)
問題報告の処理を半自動化するために、 それぞれの問題報告には機械が処理できる項目(訳註:field)がいくつかあります。 これらのうちのいくつかの値とその定義の一覧を下に示しますが、 これは何がまずいのかをより明確に特定する ためのものです(うまくいけば問題の解決が捗ります)。
下に示される項目に加えて、 NetBSDの問題報告はその問題の原因だと考えられるソフトウェアの区分に対応するいろいろな Categories (カテゴリー) に割り当てられます。 これらのカテゴリーは大まかに二つのタイプに分けられます:
- 機種独立な問題 (例えば
bin、lib、security) - ユーザーレベルのプログラムやデーモン、 ライブラリー、またカーネルの機種独立部分の問題 (NetBSDが動いているそのハードウェアの種類に関わらず同じ部分。 そのため問題は すべてのプラットフォームに影響するでしょう)。 - ポートに特有な問題 (例えば
port-alpha、port-ofppc、port-sparc) - デバイスドライバーや (例えばカーネルの割り込みハンドラーなどの)特定のCPUへの対応といった、 その問題が起こっている機種にのみ関係するであろう問題。
問題の深刻度です。 有効な値は以下の通りです:
デフォルトの値は serious です。
問題報告の提出者がどのくらい早い解決策を必要としているかを表します。 有効な値は以下の通りです:
デフォルトの値は medium です。
問題報告は次のうちのどれか一つの種類に分けられます:
デフォルトの値は sw-bug です。
NetBSD問題報告の状態 (トップ)
各々の問題報告は、 その始めから終りまでそれぞれ定められた状態を遷移していきます。 報告者には、その状態の変化が電子メールによって自動的に通知されます。
担当者が報告された問題点を解析中です。解析には問題の予備評価と、 問題の解決に必要なリソースと時間の総量を見積もることも含まれます。 これには (予定どおりにいかなかった場合の)予備手段も有り得ることを示唆しています。
問題が -current で解決していることが確認され、 適切な枝へ pullup されるのを待っている状態です。 pullup が完了するまでの間は、PR はこの状態に置かれます。
この問題についての作業は延期されています。適当な解決策が見つからないか、 現時点ではコスト対効果の点で有効でない場合にこの状態に移行します。 問題報告は継続しますが、積極的には解決を求めないようになります。 まったく問題が解決できない時には、 suspendedよりもむしろclosedにしたほうがよいでしょう。
この問題についての作業は永久に放棄されました。 この状態は、問題報告を引続き検証できる方法がまったくないような問題のためのものです。 たとえば、古いバージョンの NetBSD によってマシンがクラッシュしたとの報告が寄せられたが、 それが再現不能の場合; その問題の再現に必要なハードウェアをもはや誰も持っていない場合などです。 この "dead" 状態は、 "closed" と区別することで、 データベース検索の際に、 問題が修正済とはされていないことをすぐに調べられるようにするためのものです。
[ページの一番上へ] [PR 照会] [PR 送信] [GNATS 要約]