デバッグ
このページはバグレポートに関連する情報を集める方法を主題にしています。"デバッグ"という言葉を使ってはいますが、開発においてプログラムをデバッグする方法を解説するガイドではありません。
目次
アプリケーションが落ちる場合
コマンドラインから実行
アプリケーションが突然クラッシュしたときは、ターミナルエミュレータからアプリケーションを実行してみてください。小文字でアプリケーションの名前を入力します。パッケージの名前しか分からず、アプリケーションの実行可能ファイルの名前を知らない場合、以下のコマンドを実行することで実行可能ファイルの名前を確認できます。packagename はパッケージの名前に置き換えてください:
for f in `pacman -Ql packagename | grep "/bin/" | cut -d" " -f2`; do file $f 2>/dev/null | grep -q executable && basename $f; done
アプリケーションがセグメンテーション違反を起こしてないか確認
"segfault" という単語または "segmentation fault" というフレーズが表示された場合は、"core" という名前のファイルが存在しないか確認してください。
ls core
存在する場合、アプリケーションはセグメンテーション違反を起こしています。アプリケーションがデバッグできるようにコンパイルされている場合、"core" ファイルを使ってどこがおかしいのか調べることができます。ときどき、core ファイルがカレントディレクトリではなく、アプリケーションによって開かれたディレクトリのどれかに残ることもあります。
"core" ファイルが見つけられない場合、おそらくコアダンプがデフォルトで無効にされています。問題のプログラムを実行する前に $ ulimit -c unlimited を使ってください。.bashrc に追加すれば後でデバッグするときに役立ちます。
セグメンテーション違反
何が間違っているのか見つけ出すのに使用できるテクニックがいくつかあります。鹿撃ち帽をかぶりましょう。
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 をメモしてください。
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.
For more information, see 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-lsbAUR 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.