How to write useful bug reports/jp

From RawPedia
Jump to: navigation, search

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

 バグはフォーラムの中のバグスレッドやRawTherapeeのGoogleコードページに報告することが出来ます。もし、貴方が直面している問題がバグなのかどうなのか、加えて(或いは)Googleコードの使い方がよく分らない場合は、フォーラムのバグスレッドに報告して下さい。逆に、直面している問題の原因がバグにあることが確かで、Googleコードの書き方もご存じであれば、是非Googleコードページに報告して下さい。フォーラムのスレッドに報告されるバグレポートも、結局私達の誰かによってGoogleコードに直して再入力しなければならないので助かります。


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

  • 貴方の使っているRawTherapeeの完全なバージョン情報、プログラムを動かしているOSの完全なバージョン情報、CPUの種類、処理速度、及びRAM容量の情報が常に必要です。環境設定Gtk-preferences.pngから、左下にある“RawTherapeeについて”をクリックし、バージョンのタブを開けば、バージョン情報が記載されていますので、それをコピーしバグレポートに貼り付けて下さい。もし、タブが空の場合は、RawTherapeeのメイン画面のタイトルバーにバージョンが記載されているはずです。OSのバージョンや、RAM容量、CPUの情報に関しては、コンピューターから入手するのが簡単ですが、そのための正確な操作は使用しているOSによって異なりますので、ここでは説明を省きます。
  • バグが発生した時のrawファイルとPP3ファイルが常に必要(rawファイルの問題なのか、処理設定が問題なのか、或いはそのrawファイルがサポートされていない種のものなのか、見極める必要があるため)になりますので準備しておいて下さい。それをwww.filebin.net(英語)のようなファイルシェアリングサービスにアップロードします。
  • 問題が発生した時の画面のスクリーンショットが常に必要で、それらをwww.imgur.com(英語)にアップロードします。
  • バグレポートを送る前には、必ずフォーラムのスレッドやGoogleコードを検索して下さい。既に同じバグが報告されている可能性もありますので、重複するのを避けるためです。
  • RawTherapeeのプログラムは常に最新のバージョンをお使い下さい。旧バージョンで発生したバグが既に新しいバージョンでは修正されているかもしれません。
  • Googleコードを使用する時は、アップロードするファイルが50kを超えないよう注意して下さい。Googleコードに組み込んであるアップローダーの容量には制限がある上、一旦アップロードしてしまうと消去できないからです。よって、パッチ以外のファイルをアップロードする際は、先に紹介した二つのサイトを使って下さい。

 バグレポートについてもっと知りたい方は、以下のサイトを参照して下さい: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]のブラケットは使えないので、そのまま貼り付けます。報告の際には、これらの情報だけでなく、前述の環境設定Gtk-preferences.pngから得た、バージョン情報や、貴方のOS、CPU、処理速度、RAM容量に関する情報を付けることもお忘れなく。
    備考bt fullはクラッシュが発生したスレッドを抜き出しますが、それでは十分でなく、スレッド全てが必要な場合もあります。その時は、bt fullの代わりにall bt fullを適用します。
  7. RawTherapeeがクラッシュした時点で、GDBを止める場合は、次をタイプします:
    q
    そして、次で確認します。
    y