バグの報告

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

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

Trac のアカウントを取得する

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

バグレポートの作成

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

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

アプリケーションのバグ

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

サーバーのバグ

App server、registrar、input server のような必須のサーバーがクラッシュしたときはよくあるクラッシュアラートを見ることは無いでしょう。スクリーン全体が白で塗りつぶされ、gdb のセッションがスタートします。出力はスクリーンに直接出力されます。だいたいの場合、マウスはまだ動かすことができますが、gdb の出力を上書きします。アプリケーションも動いたままで、(たとえば、プロセスコントローラーやデスクバーの時計のように) それも gdb の出力を上書きします。
さらに、アプリケーションのバグに比べ、すべては見にくく便利ではありません。アプリケーションのバグのようにはいかないでしょう。バックトレースの取得 (bt コマンド) も、テキストのコピーができないためデジタルカメラ等を用いて写真を撮影しないとならないでしょう。

カーネルのバグ

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

システムは kernel debugging land (KDL) に入ります。画面上部はクリアされいくつかの KDL に入る原因となった理由を含むと思われる文字列が出力されます。次に、"Welcome to Kernel Debugging Land..." と出力されます。
システムは自然に再起動します。
システムは完全にフリーズします。マウスを動かすこともできず、アプリケーションも停止します。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 を失ってしまいます。

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

スクリーン上のデバッグ出力は特定の問題とすでにわかっている問題について役立つでしょう。必要でないなら使用しないでください。
これは 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 システムのメインログ。ブート中のスクリーン上デバッグと似ています。open コマンドを用いることで、必要な部分をテキストエディタに切り出すことができます。
- listimage \| grep drivers/		使用されているドライバーのリストを出力する。
- ints		Kernel Debugging Land (上記を参照) でのみ有効。割り込みの使用状況を表示する。同じ割り込みが複数のデバイスで共有されるのは好ましくありません。
- スクリーン上へのデバッグ出力 (ブート時のセーフモードオプション)

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

そして次は

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

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