How to write useful bug reports/jp

有効なバグレポートの書き方

　バグ報告は、当フォーラムやIRCではなく、必ずRawTherapee Github issue trackerで行って下さい。

　私たちは“バグ報告”という用語を広義に使っていますので、どの様な問題に関しても以下に示す詳細を必ず提供して下さい。

有効なバグレポートに必要な事項

• 　貴方が使用しているRawTherapeeの詳しいバージョン情報。バージョン情報は、をクリックし、右下の“RawTherapeeについて．．”をクリック、そして“バージョン”のタブを開けば入手できます。殆どの場合、多くの情報が入っていますので、それら全てをコピーしてバグレポートに貼り付けます。もしも情報がない場合、バージョンを知るにはメイン画面左上のタイトルバーを見て下さい。
• 　貴方が使用しているオペレーティングシステムの名前とバージョン
  • 　Windowsの場合は、（スクリーン）キーボードからのショートカット、⌘ Win+⎉ Pauseで見つけることが出来ます。
  • 　Linuxの場合は、ターミナルでuname -aを入力すれば見つけることが出来ます。
• 　問題が発生するまでの正確な手順を説明して下さい。画像を“ニュートラル”処理プロファイルで開き、問題が発生するまで貴方が行った操作の手順です。
• 　Rawファイルとpp3ファイルのアップロード。バグが発生した時のrawファイルとPP3ファイルが常に必要（rawファイルの問題なのか、処理設定が問題なのか、或いはそのrawファイルがサポートされていない種のものなのか、見極める必要があるため）になりますので準備しておいて下さい。それをwww.filebin.net（英語）のようなファイルシェアリングサービスにアップロードします。
• 　問題が発生した時の画面のスクリーンショット。その際、切り抜きは行わないで下さい。RawTherapeeのウィンドウ全体が表示されたスクリーンショットを送って下さい。
• 　“バグごとに一件”、或いは機能要請ごとに一件、の形で問題を報告します。一つの報告の中で異なるバグ修正や、異なる機能要請はしないで下さい。

　加えて、次のような作業も多くの場合役に立ちます：

• 　問題発生をビデオに記録したものです。スクリーンショットや“問題の再現”手順だけでは、その問題を上手く説明できない場合に有効です。以下のフリーソフトを使えば簡単に作成できます。
  • 　Windowsの場合は：ShareX
  • 　Linuxの場合は：SimpleScreenRecorder
• 　バグレポートを作成する前に、私たちのフォーラムや問題事項をチェックして下さい。既に他の方が同じ問題を報告しているかもしれません。同じ問題であれば、レポート作りが無駄になってしまいます。
• 　貴方が使っているRawTherapeeのバージョンが最新のものであるか確認して下さい。それ以前のバージョンにあったバグが原因で問題が発生していたのであれば、最新バージョンで既に解決されている可能性があります。
• 　貴方が抱える問題がプログラムのクラッシュの場合、出来ればスタックバックトレースを送って下さい。どの様にスタックバックトレースを手に入れるかは以下で説明します。それが難しい場合は少なくとも上記に関する最新情報を提供して下さい。そうでないと折角作成したバグレポートは役に立たないかもしれません。

　バグレポートについてもっと知りたい方は、以下のサイトを参照して下さい：http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

RawTherapeeがクラッシュした時点を特定－スタックバックトレースの紹介

　手短に言うと、バックトレースとはプログラムがクラッシュした時までのステップを打ち出したものです。私達としては、プログラムがクラッシュしたポイントを知りたい訳で、それを利用してRawTherapeeのクラッシュ原因を取り除きたいからです。

　意味のあるスタックバックトレースを得るためには、貴方に“デバッグフラッグ”の付いたRawTherapeeを使用して頂く必要があります。プログラムが動いている際に、何が起こったのか、その目的でコンパイルされたプログラムを使って知ることが、バグの修正に必要なのです。その代り、プログラムの動作が遅くなるので、通常、私達のダウンロードサイトにリンクされた殆どのバージョンには、デバッグフラッグが付いていないのです。

プログラムがデバッグであるかどうか知るには？

　方法は2つあります：

• 私達のウェブサイトのダウンロードページで、目的とするビルドの“Details”をクリックし、その中の“Build Type”と書かれたところに、“release”と書かれていれば、そのビルドがデバッグフラッグの付いていない処理速度を最適化したビルドであることを示します。一方、“debug”と書かれていれば、それが有効なスタックバックトレースを手に入れるためのビルドということになります。また、フォーラムのページでも、デバッグバージョンのrawtherapee.exeを見つけられることもありますが、この場合、貴方が使っているバージョンと同じものであることを確かめて下さい。
• RawTherapeeを起動し、“環境設定”→“RawTherapeeについて”→“バージョン”でBuild Typeと書かれた部分で、上記と同じようにデバッグか、そうでないかの判断も出来ます。

デバッグバージョン入手法

　私達のダウンロードページから、或いは貴方のパッケージマネジャーから、最新バージョンのデバッグビルドを探しますが、もし見つけられなかったら（実際には、普通見つからないでしょう）、私達にお尋ねいただくか、自らデバックバージョンを作ります。OSがLinuxであれば、非常に簡単です。Linuxによるコンパイリングの解説を参照して下さい。時々、“release”バージョンでも、幾らかの情報を得ることが出来ますが、デバッグバージョンを使う方が、はるかに有効です。

　ソフトウェアの動作というものは、デバッガーがあることで、通常環境における動作と異なる動きを示すことがよくあります。これはデバッガーがあることで、アルゴリズムの内部で働くタイミングに影響が出るからです。ですから、GDB（これもデバッガー）からRawTherapeeを動かした時、それが原因で通常使用では起こらなかったバグ（クラッシュ）に直面するかもしれません。始末に負えない困った事実ですが、幸いなことに、そういったケースはごく稀なので、進んでデバッグバージョンを手に入れて下さい。そして、貴方が悩まされていたクラッシュを再現すれば、今度は有効なスタックバックトレースが得られます。

　また、バグレポート提出をする前に、常に、ダウンロードしたプログラムが最新バージョンであることを確認してからお願いします。旧バージョンのバグが、新バージョンで既に解決済みになっている可能性があるからで、時間の無駄になってしまいます。

ステップバイステップ

1. GDBをインストールします。どの様に行うかは、貴方のOSとディストリビューション次第です。
   • Linuxの場合は、パッケージマネジャーを使います。

     Ubuntuの場合は、ターミナルを開き、以下の様に書き込みます：

     sudo apt-get install gdb

     Gentooの場合は、以下の様に書き込みます：

     sudo emerge gdb

   • Windowsの場合は、TDM-GCC（英語）をインストールし、その際にGDBのパッケージも同時にインストールします。gdb.exeをコピーし、RawTherapeeのディレクトリーに貼り付け、rawtherapee.exeと一緒の場所に置きます。
   • MacOSXに関しては、私達は不確かなので、GDBのインストールの方法を知っている方がいたら、是非私達までご連絡下さい。
2. GDBからRawTherapeeを起動します。
   • Linuxの場合、貴方がRawTherapeeのビルドでデバッグバージョンをコンパイルし、そのデバッグビルドが~/rt_default_Debug/であると仮定すれば、次を入力します：

     gdb ~/rt_default_Debug/rawtherapee

   • Windowsの場合は、コマンドプロンプトを開き、貴方のRawTherapeeディレクトリーを誘導します。仮に実行可能なRawTherapeeデバッグのファイル名が、“rawtherapee-DEBUG.exe”だとしたら、次を入力します：

     gdb rawtherapee-DEBUG.exe

3. GDBが起動し、RawTherapeeが動作する準備ができたので、次を入力します：

   run

4. RawTherapeeが動作を始めるとGDBに以下のような情報が次々と現れます：

   [New Thread 0x7fffa7b2e700 (LWP 11532)]

   [New Thread 0x7fffa9b32700 (LWP 11533)]

   [Thread 0x7fffaab34700 (LWP 11528) exited]

   [Thread 0x7fff97dfd700 (LWP 11507) exited]

   クラッシュに直面した操作を行い、RawTherapeeをクラッシュさせます。プログラムは動かなくなりますが、画面はそのままです。

5. AltキーとTabキーを同時に押して、GDBのターミナルウィンドウに戻り、次の様に入力してスタックバックトレースを手に入れます：

   bt full

6. RawTherapeeが正常に作動している間の情報は必要ないので無視して結構です。代わりにクラッシュした際の情報を探します。GDBによる操作の経験がなくとも、探すのは簡単です。必要なのは以下のような情報です：

   glibmm-ERROR **:

   unhandled exception (type std::exception) in signal handler:

   what: std::bad_alloc

   aborting...

   Program received signal SIGABRT, Aborted.

   [Switching to Thread 0x4963b70 (LWP 7111)]

   0x0012e416 in __kernel_vsyscall ()

   (gdb) bt full

   #0 0x0012e416 in __kernel_vsyscall ()

   #1 0x01205e71 in raise () from /lib/i386-linux-gnu/libc.so.6

   #2 0x0120934e in abort () from /lib/i386-linux-gnu/libc.so.6

   #3 0x00282f27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0

   #4 0x00282f62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0

   #5 0x0034c3c6 in Glib::exception_handlers_invoke() ()

   from /usr/lib/libglibmm-2.4.so.1

   #6 0x003448c0 in ?? () from /usr/lib/libglibmm-2.4.so.1

   #7 0x002a32df in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0

   #8 0x011c7e99 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0

   #9 0x012ab73e in clone () from /lib/i386-linux-gnu/libc.so.6

   クラッシュした際の必要な情報を、bt fullと一緒に全てコピーし、私達のバグスレッド、或いはRawTherapeeのGoogleコードページに貼り付けます。フォーラムのスレッドに貼り付ける場合は、 “[code］ここに貼り付ける[/code]”のように、ブラケットの中に入れて下さい。こうすることで読みやすくなります。Googleコードを使う場合は、[code]のブラケットは使えないので、そのまま貼り付けます。報告の際には、これらの情報だけでなく、前述の環境設定File:Gtk-preferences.pngから得た、バージョン情報や、貴方のOS、CPU、処理速度、RAM容量に関する情報を付けることもお忘れなく。

   備考：bt fullはクラッシュが発生したスレッドを抜き出しますが、それでは十分でなく、スレッド全てが必要な場合もあります。その時は、bt fullの代わりにall bt fullを適用します。

7. RawTherapeeがクラッシュした時点で、GDBを止める場合は、次をタイプします：

   q

   そして、次で確認します。

   y