デバッグのソースを表示

[[Category:開発]]
[[en:Step-by-step debugging guide]]
{{Related articles start}}
{{Related|一般的なトラブルシューティング}}
{{Related|バグ報告ガイドライン}}
{{Related|デバッグ - トレースを取得}}
{{Related|ブートデバッグ}}
{{Related articles end}}
このページはバグレポートに関連する情報を集める方法を主題にしています。"デバッグ"という言葉を使ってはいますが、開発においてプログラムをデバッグする方法を解説するガイドではありません。

== アプリケーションが落ちる場合 ==

=== コマンドラインから実行 ===

アプリケーションが突然クラッシュしたときは、[[アプリケーション一覧#ターミナルエミュレータ|ターミナルエミュレータ]]からアプリケーションを実行してみてください。小文字でアプリケーションの名前を入力します。パッケージの名前しか分からず、アプリケーションの実行可能ファイルの名前を知らない場合、以下のコマンドを実行することで実行可能ファイルの名前を確認できます。''packagename'' はパッケージの名前に置き換えてください:

 for f in `pacman -Ql ''packagename'' | grep "/bin/" | cut -d" " -f2`; do file $f 2>/dev/null | grep -q executable && basename $f; done

=== コアダンプが利用可能か確認 ===

コアダンプは、プロセスが予期せず終了した時のプロセスのアドレス空間 (メモリ) の内容を記録したファイルです。アプリケーションがデバッグしやすい方法でコンパイルされている場合、どこで上手く動作しなくなったのかを見つけ出すために''コア''ファイルを使うことができます。

コアダンプの場所はオペレーティングシステムの設定によって異なることがあります。システムでコアダンプの出力が有効化されているかどうか、そしてそれがどこに出力されるかを見つけるには、[[コアダンプ]]を見てください。

== セグメンテーション違反 ==

何が間違っているのか見つけ出すのに使用できるテクニックがいくつかあります。鹿撃ち帽をかぶりましょう。

=== Gdb ===

{{Pkg|gdb}} は古典的で十分テストされたデバッグ用アプリケーションです。''appname'' をデバッグしたい実行可能ファイルの名前に置き換えてください:

 $ gdb appname
 r
 (wait for segfault)
 bt full

出力を [[アプリケーション一覧#Pastebin_クライアント|Pastebin クライアント]]に投稿して URL をバグレポートに含めてください。

=== gdb の出力を改善する ===

まず '''-g''', '''-O0''', '''-fbuiltin''' フラグを付けて問題のアプリケーションを[[Arch Build System|リコンパイル]]してください。PKGBUILD の options に "!strip" があることを確認して、パッケージをインストールして上述のように gdb を再度実行します。

options 行は以下のようになります:

  options=('!strip')

'''-g''', '''-O0''', '''-fbuiltin''' を有効にするには PKGBUILD の build() 関数の一番始めに以下の二行を記述します:

 export CFLAGS="$CFLAGS -O0 -fbuiltin -g"
 export CXXFLAGS="$CXXFLAGS -O0 -fbuiltin -g"

フラグの意味は次のとおりです: '''-g''' はデバッグシンボルを有効にして '''-O0''' は最適化を無効にします ('''-O2''' が最もよく使われる最適化レベルです。[http://funroll-loops.info/ '''-O3''' は過剰] で [http://stackoverflow.com/questions/1778538/how-many-gcc-optimization-levels-are-there '''-O4''' 以上は '''-O3''' と全く同じ] です)。

"core" ファイルが存在する場合、gdb と一緒に使うことでバックトレースを取得できます:

 $ gdb appname core
 bt full

=== Valgrind ===

インライン展開された関数が無く strip されていないバイナリだとすれば、大抵の場合 {{Pkg|valgrind}} を使ってそのプログラムを実行することもよいアイデアといえます。 ''valgrind'' は CPU をエミュレートし、大抵の場合、どこでおかしくなったかを表示したり、gdb に加えてさらなる情報を提供してくれるツールです。

 $ valgrind appname

プログラムがクラッシュした場合、これによって多くの有益なデバッグ出力が得られます。さらに詳しい情報が得るには {{ic|-v}} と {{ic|<nowiki>--leak-check=full</nowiki>}} を使うとよいでしょう。

または、次を使います:

 $ valgrind --tool=callgrind appname

そして、{{Pkg|kdesdk-kcachegrind}} を使って出力ファイルを実行し、プログラムが使っている関数を視覚的に調査します。プログラムがハングした場合、これによってエラー箇所の特定が楽になります。

== 欠けているファイルやライブラリ ==

=== Strace ===

{{Pkg|strace}} はアプリケーションが実際に何をしているのかを細かく調査します。アプリケーションが存在しないファイルを開こうとしていた場合、strace でそのことを発見できます。

''appname'' という名前のプログラムが開こうとしたファイルを調査するには:

 $ strace -eopen appname

出力を保存して、[[アプリケーション一覧#Pastebin_クライアント|Pastebin クライアント]]に投稿して URL をメモしてください。

{{Tip|If you wish to grep the output from strace, you can try:
{{ic|strace -o /dev/stdout appname <nowiki>|</nowiki> grep ''string''}}
}}

=== LD_DEBUG ===

Setting {{ic|<nowiki>LD_DEBUG=files</nowiki>}} gives another overview of what files an application is looking for. For an application named ''appname'':

 LD_DEBUG=files appname > appname.log 2>&1

The output will end up in {{ic|appname.log}}.

詳しくは {{ic|man ld-linux}} を見てください。

=== Readelf ===

アプリケーションを実行した時に "no such file or directory" ｔ表示される場合は、次のコマンドを実行してみてください ({{ic|/usr/bin/appname}} は実行可能ファイルの場所に置き換えてください):

 $ readelf -a /usr/bin/appname | grep interp

Make sure the interpreter in question (like /lib/ld-linux-x86-64.so.2) actually exists. Install {{AUR|ld-lsb}} from the [[AUR]] if need be.

== C や C++ ではなく Python で書かれている場合 ==

Use {{Pkg|file}} on the executable to get more information (replace "appname" with your executable):

 $ file /usr/bin/''appname''

If it says "ELF" it's a binary exectuable and is usually written in C or C++. If it says "Python script" you know you're dealing with an application written in Python.

If it's a shell script, open up the shell script in a text editor and see (usually at the bottom of the file) if you can find the name of the real application (ELF file). You can then temporarily put "gdb" right in the shellscript, before the name of the executable, for debugging purposes. See the sections about gdb further up. Prefix the command with {{ic|gdb --args}} if the executable in question needs arguments as well.

For pure shell scripts, you can also use {{ic|bash -x ''script_name''}} or {{ic|bash -xv ''script_name''}}.

For Python applications, the output will often say which file and line number the crash occured at. If you're proficient with Python, you can try to fix this and include the fix in the bug report.

== バグの報告 ==

Please report a bug at https://bugs.archlinux.org and possibly also directly to the developers of the application in question, then include a link in the Arch Linux bug report. This helps us all.

However, if you think there's something wrong with the application itself, and not with how it is packaged, report the bug directly to upstream (which means the developers of the application). Normally, software streams from developers, through packagers/maintainers and down to users. Upstream means the other way, so for this case: directly to the developers of an application.

== 参照 ==

*[https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces Gentoo guide for getting useful backtraces]