デバッグ

関連記事

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

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

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

コマンドラインから実行

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

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

$ valgrind appname

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

または、次を使います:

$ valgrind --tool=callgrind appname

そして、kdesdk-kcachegrind^{[リンク切れ: 置換パッケージ: kcachegrind]} を使って出力ファイルを実行し、プログラムが使っている関数を視覚的に調査します。プログラムがハングした場合、これによって問題箇所の特定が楽になります。

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

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