バグの報告

開発者はすべてのハードウェア構成でテストをできません。また、オペレーティングシステムとのあらゆる関わり方をテストすることもできません。そのため私たちは、動作報告をユーザーに頼っています。そして Haiku はまだ幼いプロジェクトのため、バグに遭遇する可能性が高いです。私たちはあなたがバグ報告に時間を割いてくれることに対して感謝します。共に私たちは Haiku を少しずつ改善していくことができます。

私たちのバグトラッカーを有効に保つため、バグトラッカーでのエチケットを絶対に守ってください。

Trac アカウントを取得する

チケットを登録するには、Haiku バグトラッカーでアカウントを取得する必要があります。
アカウントを作るときは、チケットの更新通知メールを受信するために自分のメールアドレスを登録することが必要です。さまざまな確認のためのメールが届くため、アカウントを作成した後は、こまめに迷惑メールフォルダをチェックしてください。というのも、重要な確認メールがしばしば迷惑メールに分類されてしまうからです。

バグレポートの作成

バグを報告する前に、すでに報告されていないか確認してください。検索機能が有用です。
報告されていないことを確認したら、以下の情報をできる限り多く提供してください。

その問題が最新バージョンの Haiku でも再現するかを確認してください。テスト用のビルド済イメージが利用可能です。
テストした環境の情報 (物理的なハードウェア、QEMU、VMware など)
動かしているリビジョン番号について言及してください。この情報は、Deskbar メニューの Haiku について (About Haiku...) から得られます。同様にテストしている Haiku のビルドの種類 (x86_gcc2, x86_64) についても触れてください。ダウンロードイメージはビルドの種類に従って命名されています。自分でビルドしたイメージについては、どのようにビルドしたか知っておく必要があります。
できる限り正しく、実際に起きた挙動を説明し、その後自分が予測した挙動と、現在の挙動の問題を説明する
再現する手順や準備。これは開発者が再現するために必要です。
その他の情報。GUI 周りのバグやアプリケーションのバグならば、PRINT キーを押してスクリーンショットを取得してください。

アプリケーションのバグ

アプリケーションがクラッシュしたときは、レポートを保存するかコアファイルを書き込むかができ (どちらもデスクトップ上に保存されます)。それらはバグレポートに添付できます。または、デバッガーを起動します。

サーバーのバグ

App server、registrar、input server のような重要なサーバーがクラッシュしたときはよくあるクラッシュアラートを見ることは無いでしょう。その代わりに、画面全体が白で塗りつぶされ、デバッガーがテキストモードで開始します。出力はスクリーンに直接出力されます。たぶん、マウスはまだ動かせでもデバッガーの出力を上書きするでしょう。アプリケーションも動いたままで、(たとえば、プロセスコントローラーやデスクバーの時計のように) それもデバッガーの画面上への出力を上書きします。
すべては見にくく便利でないことを除けば、基本的にアプリケーションのバグと同様なものが適用できます。もっとも重要なバックトレースの取得 (bt コマンド) も、どこでもテキストのコピーができないのでデジタルカメラ等を用いて写真を撮影しないとならないでしょう。
実際にクラッシュしているものに応じて、デスクトップに save-report を使ってクラッシュレポートを保存するか、write-core で core file を保存してみてもよいです。それから電源ボタンを一度押して、手際よくシャットダウンしてみることもできます。電源ボタンが動作しない場合は、shutdown および reboot コマンドがあります。

カーネルのバグ

カーネルのバグは、もっとも重い努力を伴うバグであり、一方それと同時に、デバッグはもっとも困難なものでしょう。以下のようなさまざまな種類の症状は、そのほとんどがカーネルやドライバーのバグを示しています:

システムは kernel debugging land (KDL) に入ります。画面上部はクリアされいくつかの KDL に入る原因となった理由を含むと思われる文字列が出力されます。次に、"Welcome to Kernel Debugging Land..." と出力されます。その上に、KDL に入った直接の理由が表示されます。
システムは自発的に再起動します。
システムは完全にフリーズします。マウスを動かすこともできず、アプリケーションも停止します。ALT SysReq D (だいたいのキーボードで、SysReq は PRINT と同じキーです) を押して、KDL に入れます。
システムは正常に起動しません。起動中に再起動するか、起動中にどこかで止まるか (たとえば、ブートスクリーンでのいくつかのアイコンで) のどちらかかもしれません。後者の場合でも、ALT SysReq D を押してみてください。
システム全体または一部のハードウェアで正常な動作をしない。たとえば、動作がすごく遅い、エラーが発生する、完全に動作しない、などです。一部のハードウェアが動作しないならば、まず Haiku がそれをサポートするかどうかを確認してください (メーリングリストやフォーラムで聞いてみるなど)。

最後のポイントだけは、ハードウェアに関係あることを示すように思えますが、すべての他の症状も同様に、ハードウェアのドライバーのバグが原因で発生することがありえることに注意してください。もしドライバーやハードウェアに疑いを持っているならば、そのハードウェアを取り外すか、無効化をしてどのように変わるかを確認してください。たとえば、Wifi が問題だと疑っているならば BIOS 設定を参照して Wifi を無効化できます。設定がない場合は、問題の原因である Wifi ドライバーを Haiku のインストールからブラックリストに入れる (ブートローダーを参照ください) ことができます。

Kernel Debugging Land - KDL

システムが KDL に自動で入らなかった場合、ALT SysReq D (通常、SysReq は、Print キーです) を押して意図的に入ることができます。
ここで注意することは、KDL ではキーボードが動作しないかもしれないことです。PS/2 キーボードは常に動作します。USB キーボードは、USB コントローラーのタイプ (UHCI/EHCI) 次第です。通常、キーボードはハフを介さず、直接 USB ポートに接続されるべきです。少なくとも一度は、キーボードショートカット経由で KDL に入った場合、状況次第でキーボードのみ動作するでしょう。現時点では、USB OHCI はサポートされていません。

KDL 自体はシェルの一種です。システム情報を出力するコマンドを実行できますす。次のコマンドが役に立つでしょう:

bt (別名 sc)		バックトレースを出力する。システムが自ら KDL に入った場合、これを必ず実行する。
ints		処理される / 処理されないハードウェア割り込みを表示。
co (または continue)		カーネルデバッガーを離れ、可能ならばシステムの実行に戻る。
reboot		システムをすぐに再起動する。まだ保存されていないすべてのデータ、保存はしていてもまだディスクに書き込まれていないデータは失われる。

詳細は Kernel Debugging Land へようこそも参照してください。

KDL はシリアルポートと syslog にも出力します (もしあるならば。シリアルケーブルをもう一つのコンピューターに接続し、出力を受け取れます)。KDL を終了できない場合 syslog には出力されませんが、ブートローダーのデバッグ用オプションがそれを可能にするでしょう (下記も参照ください)。

KDL の出力から QR コードを生成できます。QR コードは、スマートフォンなどを使ってテキストに変換できます。この機能を使った KDL データの取り出しについては、次のブログ投稿、QR Encode your KDL Output を参照してください。

Syslog

これは起動しないシステムから情報を取得するためのものです。
syslog (system log の略称) はシステムに発生した有益な情報を含んでいます。それは、KDL セッションの出力を含んでいます。それをカーネル関連の Trac チケットに添付することは良いことです。syslog は /boot/system/var/log/syslog に記録されます。ファイルの書き込みには動作しているシステムが必要であり、直近の出力が書き込まれず、カーネルの問題が起きた瞬間を記録していないかもしれません (おもに突然のリブートや続行不能な KDL のセッションで)。

ブートローダーの Debug menu にある Enable debug syslog オプションは syslog を記録します。Save syslog from previous session during boot オプションがブートローダーオプションで有効な場合 (実際デフォルトです)、最新のセッションの syslog は、/boot/system/var/log/previous_syslog に見つかるでしょう。
ブートしても、previous_syslog が得られない場合は、起動するときに SHIFT を押したままにしてブートローダーメニューに入る必要があります。
ブートローダーメニューにある Debug menu の中には Display syslog from previous session と Save syslog from previous session があります。前者は syslog をスクリーンに表示し、後者はディスクに保存します。現時点では FAT32 フォーマットのみサポートされていることに注意してください。USB メモリを使用する場合は、後から接続しても認識しないので 1 度再起動し、再度ブートローダーメニューに入る必要があります。注意: 誤ってほかのオペレーションシステムを実行しないようにしてください。syslog を失ってしまいます。

画面上でのデバッグ

画面上のデバッグ出力は極めて特定の問題にのみ役立ち、(タイミングの) 問題を持つことがわかっています。必要でないなら使用しないでください。
これは Haiku がユーザーのマシンでうまく起動せず、なおかつ何らかの理由で Debug syslog option もうまく動作しないときに使います。Haiku の起動ロゴが現れる前に、SHIFT を押したままにしてブートローダーメニューに入り、Select safe mode options を選びます。下の方に [ ] Enable on screen debug output がリストにあります (注意: ほかのオプションも Haiku のブートを試みる際に有効にできます。Haiku がひとつ以上のオプションを有効にした時のみ起動する場合は、必ずどのオプションかを挙げるようにしてください)。
最後に、Return to main menu を選択し、それから Continue booting を選択します。
1 ページ以上のテキストが画面に表示されますが、最後の数行のみがチケットに添付する必要がある物でしょう。詳細は、ブートローダーを参照ください。

ハードウェアとドライバーのバグ

もしハードウェアやドライバーのバグに関連したバグを扱うならば、以下の情報を添付する必要があります:

- listdev		ベンダーと PCI id を含む詳細なハードウェアのリストを出力します。Linux の lshw と lspci に似ています。
- listusb -v		USB 関連のバグを取り扱うときに使用します。Linux の lsusb に似ています。
- open /var/log/syslog		Haiku で使用するシステムのメインログ、上の Syslog を参照ください。ブート中の画面上デバッグと似ています。open コマンドを用いることで、syslog の関連する部分をテキストエディターに切り出せます。
- listimage \| grep drivers/		使用されているドライバーのリストを出力する。
- ints		Kernel Debugging Land (上記を参照) でのみ有効。割り込みの使用状況を表示します。同じ割り込みが複数のデバイスで共有されるのは好ましくありません。
- 画面上へのデバッグ出力 (ブート時のセーフモードオプション上を参照)

最初の 4 つのコマンドはターミナルに入力できます。> output.txt をコマンドの最後に追加すると、"output.txt" というテキストファイルに出力されます。つまり、それをバグレポートやメールに添付できます。

次はどうする

バグをレポートした後は、開発者があなたの報告を見て修正を試みるでしょう。しかし忘れないでいてもらいたいのは、私たちはボランティアであるので、しばらくの間報告が放置されることもあります。情報を追加することで早くバグを修正できるようになります。しかし、説明的でないコメントを追加することはしないでください。

バグのレポートはあなたの時間を無駄に消費するわけではありません。バグの報告をしたあなたは一つの Haiku の開発プロセスにあります。開発者はバグを修正するために質問をすることがあります。それを無視せず、質問には答えるようにしてください。あなたの参加は、バグが 'fixed' となるまで終わりません。