バグの報告

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

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

Trac アカウントを取得する

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

バグレポートの作成

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

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

アプリケーションのバグ

アプリケーションがクラッシュしたときは、ポップアップしたダイアログからデバッガーを起動すべきです。そうすれば gdb (GNU デバッガー) がターミナル画面の上で起動します。bt と入力すると "バックトレース" が出力されるので、それをそのままコピーし (bt と入力する前も含める) 、そのままチケットに添付してください。

サーバーのバグ

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

カーネルのバグ

カーネルのバグのデバッグはもっとも難しいでしょう。カーネルやドライバーのバグにはこのようなさまざまな症状があります:

システムは 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 を押して手動で入れます。
KDL ではキーボードが動作しないかもしれません。PS/2 キーボードは常に動作します。UHCI コントローラーに接続された 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 を失ってしまいます。

スクリーン上でのデバッグ

The on-screen debug output is useful only for debugging very specific issues and is known to have (timing) issues. Don't use it, if you don't have to.
This is only relevant when Haiku fails to boot on your machine and the Debug syslog option doesn't work for some reason. Before the Haiku boot logo appears, hold SHIFT to enter the boot loader menu. Select Select safe mode options. Near the bottom, [ ] Enable on screen debug output will be listed. (Note: The other options could be enabled in an attempt to boot Haiku. If Haiku will boot only when one or more options are activated, be sure to mention which ones.)
Finally select Return to main menu and then Continue booting.
One or more pages of text will display on the screen, only the last few lines need to be included on your ticket. There's more information on the Boot Loader.

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

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

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

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

そして次は

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

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