デバッグ

関連記事

• 一般的なトラブルシューティング
• バグ報告ガイドライン
• デバッグ - トレースを取得
• ブートデバッグ

このページはバグレポートに関連する情報を集める方法を主題にしています。"デバッグ"という言葉を使ってはいますが、開発においてプログラムをデバッグする方法を解説するガイドではありません。

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

コマンドラインから実行

アプリケーションが突然クラッシュしたときは、ターミナルエミュレータからアプリケーションを実行してみてください。小文字でアプリケーションの名前を入力します。パッケージの名前しか分からず、アプリケーションの実行可能ファイルの名前を知らない場合、以下のコマンドを実行することで実行可能ファイルの名前を確認できます。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

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

$ gdb appname
r
(wait for segfault)
bt full

出力を Pastebin クライアントに投稿して URL をバグレポートに含めてください。

gdb の出力を改善する

まず -g, -O0, -fbuiltin フラグを付けて問題のアプリケーションをリコンパイルしてください。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 が最もよく使われる最適化レベルです。-O3 は過剰 で -O4 以上は -O3 と全く同じ です)。

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

$ gdb appname core
bt full

Valgrind

Assuming you have an unstripped binary without inlined functions, it's usually a good idea to also run that program through valgrind. valgrind is a tool that emulates a CPU and usually shows where things go wrong or provide additional info in addition to gdb.

$ valgrind appname

it will provide a lot of helpful debug output if there is a crash. Consider -v and --leak-check=full to get even more info.

Alternatively, use:

$ valgrind --tool=callgrind appname

and run the output through kdesdk-kcachegrind to graphically explore the functions the program uses. If a program hangs, this makes it easier to pinpoint the location of the error.

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

Strace

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

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

$ strace -eopen appname

出力を保存して、Pastebin クライアントに投稿して URL をメモしてください。

ヒント: If you wish to grep the output from strace, you can try:

strace -o /dev/stdout appname | grep string

LD_DEBUG

Setting LD_DEBUG=files 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 appname.log.

詳しくは man ld-linux を見てください。

Readelf

アプリケーションを実行した時に "no such file or directory" ｔ表示される場合は、次のコマンドを実行してみてください (/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 ld-lsb^AUR from the AUR if need be.

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

Use 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 gdb --args if the executable in question needs arguments as well.

For pure shell scripts, you can also use bash -x script_name or 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.

参照

• Gentoo guide for getting useful backtraces