バグの報告

開発者はあらゆるハードウェア構成でテストすることは不可能です。さまざまな要因がオペレーティングシステムに影響を与えるため、私たちはユーザーの動作の報告などの情報に頼っています。そして 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 を押して KDL に入ることができると思われます。
システム全体もしくは一部のハードウェアで正常な動作をしない。たとえば、それがすごく遅く動作する、エラーが発生する、完全に動作しない、などです。一部のハードウェアが動作をしないならば、まず Haiku がそれをサポートするかどうかを確認してください (メーリングリストやフォーラムで聞いてみるなど)

最後の例でハードウェアに関連すると思われる場合は、その動作がドライバーのバグかもしれません。もしドライバーやハードウェアに疑いを持っているならば、そのハードウェアを取り外したり無効化をするなどしてどのように変わるかを確認してください。たとえば、Wifi が問題だと疑っているならば BIOS の設定を参照して Wifi を無効化したり、 Wifi ドライバーを Haiku のインストール作業で取り除く (/boot/system/add-ons/kernel/drivers/bin の中にあります) 等といったことです。

Kernel Debugging Land - KDL

システムが KDL に自動で入らなかった場合、 ALT SysReq D を押して手動で入ることができます。
KDL ではキーボードが動作しないかもしれません。PS/2 キーボード、 UHCI コントローラーに接続された USB キーボードは動作するでしょう。キーボードはショートカットでの起動で利用した一つに限られます。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/common/var/log/syslog に記録されます。ファイルの書き込みには動作しているシステムが必要であり、直近の出力が書き込まれず、カーネルの問題が起きた瞬間を記録していないかもしれません (おもに突然のリブートや続行不能な KDL のセッションで)。

ブートローダーの Debug menu にある Enable debug syslog オプションは syslog を記録します。デフォルトでこのオプションは有効で、リブートがかかってもブートローダーメニューから直接アクセスできるようにします。オペレーティングシステム (Haiku 含めあらゆるシステム) を起動すると 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' となるまで終わりません。