デバッグのソースを表示

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

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

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

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

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

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

=== Gdb ===

{{Pkg|gdb}} は、アプリケーションをデバッグするための古くからある十分にテストされたアプリケーションです。これを使用してトレースを取得する方法の詳細については、[[デバッグ/トレースを取得#トレースの取得]] を参照してください。  {{ic|gdb}} からの実行中に、セグメンテーション違反が発生するまで待機する必要があります。その後、トレース [[アプリケーション一覧#Pastebin_クライアント|Pastebin クライアント]] に URL を含めてバグレポートを投稿して下さい。

"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|kcachegrind}} を使って出力ファイルを実行し、プログラムが使っている関数を視覚的に調査します。プログラムがハングした場合、これによって問題箇所の特定が楽になります。

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

=== Strace ===

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

''appname'' という名前のプログラムが開こうとしているファイルを見つけるには:

 $ strace -eopen appname

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

{{Tip|strace からの出力を grep したい場合、次のコマンドを試してみてください: {{ic|strace -o /dev/stdout appname <nowiki>|</nowiki> grep ''string''}}}}

=== LD_DEBUG ===

{{ic|<nowiki>LD_DEBUG=files</nowiki>}} を設定することでアプリケーションがどのようなファイルを必要としているのか確認できます。例えばアプリケーションの名前が ''appname'' の場合:

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

出力は {{ic|appname.log}} に書き込まれます。

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

=== Readelf ===

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

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

インタプリタ (/lib/ld-linux-x86-64.so.2 など) が存在することを確認してください。必要であれば [[AUR]] から {{Pkg|ld-lsb}} をインストールしてください。

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

実行ファイルに対して {{Pkg|file}} を使って情報を取得してください ("appname" は実行ファイルに置き換えてください):

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

"ELF" と出力される場合、ファイルはバイナリ実行ファイルであり、大抵は C あるいは C++ などで書かれています。"Python script" と出力される場合、Python で書かれたアプリケーションです。

シェルスクリプトの場合、テキストエディタでシェルスクリプトを開いて実際に呼ばれるアプリケーション (ELF ファイル) の名前がないか確認してください (大抵はファイルの末尾に存在します)。シェルスクリプトの中で実行ファイルの名前の前に "gdb" を追加することでデバッグできます。gdb については上のセクションを参照してください。実行ファイルが引数を必要とする場合はコマンドの前に {{ic|gdb --args}} を付けます。

純粋なシェルスクリプトの場合、{{ic|bash -x ''script_name''}} や {{ic|bash -xv ''script_name''}} でデバッグすることが可能です。

Python アプリケーションの場合、クラッシュが発生した行番号やファイルなどが出力されます。Python に精通しているのであれば、修正できるか試してみてバグレポートに修正内容を加えても良いでしょう。

== バグの報告 ==

まず、問題のバグがパッケージングのバグであるかどうかを確認します。Arch Linux がこのアプリケーションをパッケージ化する方法が原因でバグが発生した場合は、https://gitlab.archlinux.org/groups/archlinux/packaging/-/issues に報告してください。これには、ライブラリまたは依存関係に関する問題も含まれます (たとえば、それらの 1 つが必要な特定の機能を備えて構築されていない場合)
パッケージの PKGBUILD を検査して ([[Arch build system]] で)、どのようにパッケージ化されているかを確認します。
詳細については、[[バグ報告ガイドライン#上流か Arch か?]] を参照してください。

バグが Arch Linux に関連しておらず、他の場所でも再現できる場合は、上流にのみ報告してください。Arch Linux は上流のバグを魔法のように修正することはできません。Arch バグトラッカーに報告しても役に立たず、バグ管理者の時間を無駄にする傾向があるため、逆効果になる可能性さえあります。

== 参照 ==

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