デバッグ - 版の履歴

Kgx: /* バグの報告 */ 同期

2024-03-24T12:32:02Z

バグの報告: 同期

← 古い版		2024年3月24日 (日) 21:32時点における版
92行目:		92行目:
	== バグの報告 ==		== バグの報告 ==

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

			バグが Arch Linux に関連しておらず、他の場所でも再現できる場合は、上流にのみ報告してください。Arch Linux は上流のバグを魔法のように修正することはできません。Arch バグトラッカーに報告しても役に立たず、バグ管理者の時間を無駄にする傾向があるため、逆効果になる可能性さえあります。
	ただし、パッケージングとは無関係の問題がアプリケーション自体に何かあると考えられる場合、上流 (アプリケーションの開発者) に直接バグを報告してください。基本的に、ソフトウェアは開発者からパッケージ作成者・メンテナを介してユーザーに届けられます。上流とはアプリケーションの開発者を示します。

	== 参照 ==		== 参照 ==

Kgx: /* Strace */ 翻訳を修正

2024-03-24T12:27:21Z

Strace: 翻訳を修正

← 古い版		2024年3月24日 (日) 21:27時点における版
48行目:		48行目:
	=== Strace ===		=== Strace ===

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

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

	$ strace -eopen appname		$ strace -eopen appname
56行目:		56行目:
	出力を保存して、[[アプリケーション一覧#Pastebin_クライアント\|Pastebin クライアント]]に投稿して URL をメモしてください。		出力を保存して、[[アプリケーション一覧#Pastebin_クライアント\|Pastebin クライアント]]に投稿して URL をメモしてください。

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

	=== LD_DEBUG ===		=== LD_DEBUG ===

Kgx: 他言語へのリンクを追加

2024-03-22T11:02:18Z

他言語へのリンクを追加

← 古い版		2024年3月22日 (金) 20:02時点における版
2行目:		2行目:
	[[Category:システム管理]]		[[Category:システム管理]]
	[[en:Step-by-step debugging guide]]		[[en:Step-by-step debugging guide]]
			[[ru:Debugging]]
	{{Related articles start}}		{{Related articles start}}
	{{Related\|一般的なトラブルシューティング}}		{{Related\|一般的なトラブルシューティング}}

Kgx: /* セグメンテーション違反 */ 項目を整理

2024-03-22T11:01:11Z

セグメンテーション違反: 項目を整理

← 古い版		2024年3月22日 (金) 20:01時点における版
27行目:		27行目:

	$ gdb ''appname'' core		$ gdb ''appname'' core
	bt full

	=== 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''' は過剰] で [https://stackoverflow.com/questions/1778538/how-many-gcc-optimization-levels-are-there '''-O4''' 以上は '''-O3''' と全く同じ] です)。

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

	$ gdb appname core
	bt full		bt full

Kgx: /* アプリケーションが落ちる場合 */ 同期

2024-03-22T11:00:17Z

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

← 古い版		2024年3月22日 (金) 20:00時点における版
10行目:		10行目:
	このページはバグレポートに関連する情報を集める方法を主題にしています。"デバッグ"という言葉を使ってはいますが、開発においてプログラムをデバッグする方法を解説するガイドではありません。		このページはバグレポートに関連する情報を集める方法を主題にしています。"デバッグ"という言葉を使ってはいますが、開発においてプログラムをデバッグする方法を解説するガイドではありません。

	== ア~~プリケーショ~~ンが~~落ちる場合~~ ==		== コアダンプが利用可能か確認 ==

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

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

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

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

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

Kgx: /* Gdb */ 同期

2024-03-22T10:57:51Z

Gdb: 同期

← 古い版		2024年3月22日 (金) 19:57時点における版
30行目:		30行目:
	=== Gdb ===		=== Gdb ===

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

			"core" ファイルがある場合は、それを gdb と一緒に使用してバックトレースを取得できます:
⚫	$ gdb appname
	r
	(wait for segfault)
⚫	bt full

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

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

Kusanaginoturugi: カテゴリを追加

2022-08-25T02:10:33Z

カテゴリを追加

← 古い版		2022年8月25日 (木) 11:10時点における版
1行目:		1行目:
	[[Category:開発]]		[[Category:開発]]
			[[Category:システム管理]]
	[[en:Step-by-step debugging guide]]		[[en:Step-by-step debugging guide]]
	{{Related articles start}}		{{Related articles start}}

Kusanaginoturugi: Kusanaginoturugi がページ「ステップバイステップデバッグガイド」を「デバッグ」に移動しました: 英語版に追従

2022-08-25T02:09:58Z

Kusanaginoturugi がページ「ステップバイステップデバッグガイド」を「デバッグ」に移動しました: 英語版に追従

← 古い版	2022年8月25日 (木) 11:09時点における版
(相違点なし)

Kusakata.bot: Pkg/AUR テンプレートの更新

2018-12-19T14:48:00Z

Pkg/AUR テンプレートの更新

← 古い版		2018年12月19日 (水) 23:48時点における版
102行目:		102行目:
	$ readelf -a /usr/bin/appname \| grep interp		$ readelf -a /usr/bin/appname \| grep interp

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

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

Kusakata.bot: 文字列「http://stackoverflow.com/」を「https://stackoverflow.com/」に置換

2018-02-06T14:43:06Z

文字列「http://stackoverflow.com/」を「https://stackoverflow.com/」に置換

← 古い版		2018年2月6日 (火) 23:43時点における版
51行目:		51行目:
	export CXXFLAGS="$CXXFLAGS -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''' と全く同じ] です)。		フラグの意味は次のとおりです: '''-g''' はデバッグシンボルを有効にして '''-O0''' は最適化を無効にします ('''-O2''' が最もよく使われる最適化レベルです。[http://funroll-loops.info/ '''-O3''' は過剰] で [https://stackoverflow.com/questions/1778538/how-many-gcc-optimization-levels-are-there '''-O4''' 以上は '''-O3''' と全く同じ] です)。

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