「デバッグ/トレースを取得」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(英語版と同期、非公式user repository 使い方はそのまま)
(カテゴリを追加)
 
(3人の利用者による、間の17版が非表示)
1行目: 1行目:
 
[[Category:パッケージ開発]]
 
[[Category:パッケージ開発]]
  +
[[Category:開発]]
[[en:Debug - Getting Traces]]
 
  +
[[en:Debugging/Getting traces]]
 
[[pt:Debug - Getting Traces]]
 
[[pt:Debug - Getting Traces]]
[[ru:Debug - Getting Traces]]
+
[[ru:Debugging (Русский)/Getting traces]]
[[zh-hans:Debug - Getting Traces]]
+
[[zh-hans:Debugging/Getting traces]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|一般的なトラブルシューティング}}
 
{{Related|一般的なトラブルシューティング}}
10行目: 11行目:
 
{{Related articles end}}
 
{{Related articles end}}
 
この記事では Arch パッケージを作成するときにトレースを取得したり、開発者にソフトウェアのバグを報告するのに役立つデバッグ情報を集める方法を解説します。
 
この記事では Arch パッケージを作成するときにトレースを取得したり、開発者にソフトウェアのバグを報告するのに役立つデバッグ情報を集める方法を解説します。
  +
  +
通常、実行可能ファイルは、サイズを小さくするために、人間の読める情報が取り除かれています。それだけでなく、そもそも、拡張されたデバッグ情報も通常、実行ファイルに追加されないので、トレースの品質が大幅に劣化します。なので、デバッグ情報のあるトレースを得る前に、デバッグ情報を取り除かずにパッケージを再ビルドする必要があります。
  +
  +
発見したバグを開発者に知らせるときは完全なスタックトレースを使ってください。プログラムの開発に役に立ちます。
   
 
== パッケージの名前 ==
 
== パッケージの名前 ==
36行目: 41行目:
 
パッケージの名前は {{Pkg|glibc}} でバージョンが 2.5-8 とわかりました。デバッグが必要なパッケージの数だけ同じ手順を繰り返してください。
 
パッケージの名前は {{Pkg|glibc}} でバージョンが 2.5-8 とわかりました。デバッグが必要なパッケージの数だけ同じ手順を繰り返してください。
   
== PKGBUILD ==
+
== Debuginfod ==
   
  +
[[公式リポジトリ]] でサポートしているパッケージ [https://debuginfod.archlinux.org/packages] では、[[debuginfod]] を使って HTTP で直接デバッグ情報を取得することができます。
ソースからパッケージをビルドするには、[[PKGBUILD]] ファイルが必要です。[[公式リポジトリ]]のパッケージについては [[ABS]] を、[[AUR]] のパッケージについては [[AUR#ビルドファイルを獲得]] を見てください。
 
   
  +
''gdb'' は、{{ic|DEBUGINFOD_URLS}} [[環境変数]] が設定されている場合に、それらを自動的にダウンロードすることを提案します。
== コンパイル設定 ==
 
  +
この変数はデフォルトで {{ic|/etc/profile.d/}} に設定されます。
  +
  +
{{hc|$ gdb ''application''|2=
  +
This GDB supports auto-downloading debuginfo from the following URLs:
  +
<https://debuginfod.archlinux.org>
  +
Enable debuginfod for this session? (y or [n]) y
  +
Debuginfod has been enabled.
  +
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
  +
Downloading separate debug info for /usr/bin/''application''
  +
Reading symbols from /home/user/.cache/debuginfod_client/fbaee841e2ed2c11ecbbda26f39eeec1da23d6c3/debuginfo...
  +
}}
  +
  +
debuginfo サポートを有効にしたら、[[デバッグ/トレースを取得#トレースの取得|トレースの取得]] に進むことができます。
  +
  +
=== マニュアルダウンロード ===
  +
  +
{{Pkg|zstd}} のデバッグシンボルといくつかのソースファイルを手動で取得したい場合は、''debuginfod-find'' を利用できます。
  +
  +
{{hc|$ debuginfod-find debuginfo /usr/bin/zstd|
  +
/home/user/.cache/debuginfod_client/70e1b456c5813658df6436a3deb71812e75a0267/debuginfo
  +
}}
  +
  +
{{hc|$ debuginfod-find source /usr/bin/zstd /usr/src/debug/zstd-1.5.2/programs/fileio.c|
  +
/home/user/.cache/debuginfod_client/70e1b456c5813658df6436a3deb71812e75a0267/source##usr##src##debug##zstd-1.5.2##programs##fileio.c}}
  +
  +
== デバッグ情報を手動で取得する ==
  +
  +
最初に行うことは、[[デバッグ/トレースを取得#パッケージを再構築する|再構築が必です]] または [[デバッグ/トレースを取得#デバッグパッケージのインストール|デバッグパッケージのインストール]] のパッケージの名前を取得することです。
  +
  +
[...]
  +
Backtrace was generated from '/usr/bin/epiphany'
  +
  +
'''(no debugging symbols found)'''
  +
Using host libthread_db library "'''/lib/libthread_db.so.1'''".
  +
'''(no debugging symbols found)'''
  +
[...]
  +
  +
たとえば、トレースからの上記の抜粋の場合、関連するパッケージのパッケージ名は [[pacman]] で取得できます。
  +
  +
{{hc|$ pacman -Qo /lib/libthread_db.so.1|
  +
/lib/libthread_db.so.1 is owned by ''glibc'' 2.5-8
  +
}}
  +
  +
このパッケージは、バージョン 2.5-8 {{Pkg|glibc}} という名前です。デバッグ情報が必要なパッケージごとにこの手順を繰り返します。
  +
  +
=== デバッグパッケージをインストールする ===
  +
  +
{{Note|デバッグパッケージは、Arch Linux によって [[Arch Linux Archive]] にアーカイブされません。}}
  +
  +
現在、いくつかのミラーがアクセス可能なリポジトリにデバッグパッケージを配布しています。これらは Arch Linux によって制御されるスポンサー付きミラーであり、デバッグリポジトリへのアクセスが許可されています。
  +
  +
* https://geo.mirror.pkgbuild.com (GeoDNS ミラー)
  +
  +
パッケージをインストールするには、リポジトリから直接インストールできます。例えば:
  +
  +
# pacman -U <nowiki>https://geo.mirror.pkgbuild.com/core-debug/os/x86_64/</nowiki>''zstd-debug-1.5.2-2''-x86_64.pkg.tar.zst
  +
  +
{{Warning|両方のミラーが同期していない場合、1 つの [[ミラー]] からのデバッグパッケージは、別のミラーからの通常のパッケージと互換性がなく、ビルドが一致しません。この場合、異なるミラーからのパッケージを混合することは避けてください ([[部分アップグレード]] が発生します) ただし、すべてのリポジトリが {{ic|debug}} ミラーを指すようにしてください。}}
  +
  +
{{Merge|公式リポジトリ|公式リポジトリには、デバッグパッケージを配布する専用ページ|section=mirrors があります。}}
  +
  +
もう 1 つのオプションは、pacman 設定にリポジトリを追加することです。
  +
  +
{{hc|/etc/pacman.conf|2=
  +
# Testing Repositories
  +
  +
[core-testing-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
  +
[extra-testing-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
  +
[multilib-testing-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
  +
# Stable repositories
  +
  +
[core-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
  +
[extra-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
  +
[multilib-debug]
  +
Include = /etc/pacman.d/mirrorlist
  +
}}
  +
  +
デバッグパッケージを含むミラーをミラーリストファイルの最初のミラーとして配置します。
  +
  +
{{hc|/etc/pacman.d/mirrorlist|2=
  +
Server = <nowiki>https://geo.mirror.pkgbuild.com/$repo/os/$arch</nowiki>
  +
...
  +
}}
  +
  +
=== パッケージを再構築する ===
  +
  +
デバッグ情報が ''debuginfod'' を通じて公開されていない場合 (たとえば、パッケージが [[AUR]] から生成されている場合)、ソースから再構築できます。[[公式リポジトリ]] のパッケージについては [[ABS]] を、[[AUR]] のパッケージについては [[Arch User Repository#ビルドファイルを取得する]] を参照してください。
   
 
ここで、デバッグ目的でしか makepkg を使用しない場合は {{ic|makepkg}} のグローバルな設定ファイルを編集してください。そうではない場合は、リビルドしたいパッケージの PKGBUILD だけを修正してください。
 
ここで、デバッグ目的でしか makepkg を使用しない場合は {{ic|makepkg}} のグローバルな設定ファイルを編集してください。そうではない場合は、リビルドしたいパッケージの PKGBUILD だけを修正してください。
   
=== 一般 ===
+
==== コンパイル設定 ====
   
 
pacman 4.1 現在、{{ic|/etc/makepkg.conf}} のデバッグコンパイルフラグには {{ic|DEBUG_CFLAGS}} と {{ic|DEBUG_CXXFLAGS}} があります。これらを使うには、makepkg オプションの {{ic|debug}} を有効化して {{ic|strip}} を無効化してください。
 
pacman 4.1 現在、{{ic|/etc/makepkg.conf}} のデバッグコンパイルフラグには {{ic|DEBUG_CFLAGS}} と {{ic|DEBUG_CXXFLAGS}} があります。これらを使うには、makepkg オプションの {{ic|debug}} を有効化して {{ic|strip}} を無効化してください。
57行目: 159行目:
   
 
{{Note|新しくコンパイルしたデバッグパッケージをインストールするだけでは不十分です。デバッガは関連するライブラリや実行ファイルと同じビルドからデバッグシンボルが含まれたファイルを確認するためです。再コンパイルしたパッケージを両方ともインストールしてください。Arch ではデバッグシンボルファイルは {{ic|/usr/lib/debug}} に、ソースコードは {{ic|/usr/src/debug}} にインストールされます。デバッグパッケージについて詳しくは [https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html GDB のドキュメント] を参照してください。}}
 
{{Note|新しくコンパイルしたデバッグパッケージをインストールするだけでは不十分です。デバッガは関連するライブラリや実行ファイルと同じビルドからデバッグシンボルが含まれたファイルを確認するためです。再コンパイルしたパッケージを両方ともインストールしてください。Arch ではデバッグシンボルファイルは {{ic|/usr/lib/debug}} に、ソースコードは {{ic|/usr/src/debug}} にインストールされます。デバッグパッケージについて詳しくは [https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html GDB のドキュメント] を参照してください。}}
  +
  +
===== Glibc =====
   
 
''glibc'' など特定のパッケージは設定に関係なくデバッグ情報が取り除かれます。PKGBUILD の中を確認してください:
 
''glibc'' など特定のパッケージは設定に関係なくデバッグ情報が取り除かれます。PKGBUILD の中を確認してください:
77行目: 181行目:
 
そして必要であれば記述を削除してください。
 
そして必要であれば記述を削除してください。
   
=== Qt4 ===
+
===== Clang =====
   
  +
[[Clang]] をコンパイラとして使用するパッケージは、デバッグフラグ {{ic|-fvar-tracking-assignments'}} が処理されないため、{{ic|debug}} オプションではビルドされません (例: {{Pkg|js78}})
上記の汎用設定に加えて、{{ic|PKGBUILD}} の {{ic|configure}} スクリプトに {{ic|-developer-build}} オプションを指定してください。デフォルトでは {{ic|-developer-build}} はコンパイラに {{ic|-Werror}} を渡すため、コンパイルが失敗するようになる可能性があります。そのような場合コンパイルエラーを防ぐために、{{ic|-no-warnings-are-errors}} も追加する必要があります。
 
   
  +
影響を受けるパッケージのフラグのみを削除するには、{{ic|build()}} 関数の先頭に次のコードを追加します。
=== Qt5 ===
 
   
  +
{{bc|1=
[[非公式ユーザーリポジトリ#qt-debug|qt-debug]] リポジトリにはデバッグシンボルが含まれた Qt/PyQt パッケージが入っています。[https://doc.qt.io/qt-5/debug.html 上流] の手順も参照。
 
  +
build() {
  +
CFLAGS=${CFLAGS/-fvar-tracking-assignments}
  +
CXXFLAGS=${CXXFLAGS/-fvar-tracking-assignments}
  +
[...]
  +
}}
  +
  +
===== LTO =====
   
  +
[[w:Interprocedural_optimization#WPO_and_LTO|リンク時最適化 (LTO)]] を使用すると、コンパイル時とデバッガーの両方で、より多くのメモリを使用します [https://pp.ipd.kit.edu/uploads/publikationen/weinreuter16bachelorarbeit.pdf#section.4.3] [https://sourceware.org/bugzilla/show_bug.cgi?id=23710] アプリケーションによっては、特に Firefox や Qt のような大規模なアプリケーションの場合、使用可能なメモリを超える可能性があります。この問題が発生した場合は、LTO を使用せずにアプリケーションをビルドしてください。
=== CMAKE (KDE) アプリケーション ===
 
   
  +
公式リポジトリ内のすべてのパッケージは通常、LTO でビルドされます。
[[KDE]] と関連するプログラムは基本的に {{Pkg|cmake}} を使っています。デバッグ情報を有効にして最適化を解除するには {{ic|-DCMAKE_BUILD_TYPE}} を {{ic|Debug}} に、KDE アプリケーションでは {{ic|debugfull}} [https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_symbols] に変更してください。最適化を有効にしたままデバッグ情報を有効にしたい場合は {{ic|-DCMAKE_BUILD_TYPE}} を {{ic|RelWithDebInfo}} に変更してください。
 
   
== パッケージのビルドとインストール ==
+
==== パッケージのビルドとインストール ====
   
 
PKGBUILD のディレクトリから {{ic|makepkg}} を使ってソースからパッケージを作成します。多少時間がかかります:
 
PKGBUILD のディレクトリから {{ic|makepkg}} を使ってソースからパッケージを作成します。多少時間がかかります:
140行目: 251行目:
 
(gdb) continue
 
(gdb) continue
   
クラッシュしたアプリケーションをデバッグしたいときは、[[コアダンプ#コアダンプの確認|コアダンプ]]に対して gdb を起動すると良いでしょう。
+
クラッシュしたアプリケーションをデバッグしたいときは、[[コアダンプ#コアダンプの確認|コアダンプ]] に対して gdb を起動すると良いでしょう。
   
== まとめ ==
+
== 参照 ==
   
  +
* [[Debian:HowToGetABacktrace]]
発見したバグを開発者に知らせるときは完全なスタックトレースを使ってください。プログラムの開発に役に立ちます。
 
  +
* [[Gentoo:Project:Quality Assurance/Backtraces]]
 
  +
* [[Fedora:StackTraces]]
== 参照 ==
 
  +
* [https://wiki.gnome.org/GettingInTouch/Bugzilla/GettingTraces/Details#Obtaining_a_stack_trace_.28the_easy_way.29 GNOME - Getting Stack Traces]
  +
* [https://linux.bytesex.org/gdb.html gdb mini intro]
   
  +
{{TranslationStatus|Debugging/Getting traces|2023-10-15|715225}}
* [https://wiki.debian.org/HowToGetABacktrace Debian - How To Get a Backtrace]
 
* [https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces Gentoo Wiki - Backtraces with Gentoo]
 
* [https://fedoraproject.org/wiki/StackTraces Fedora - StackTraces]
 
* [https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details#obtain-a-stacktrace GNOME - Getting Stack Traces]
 
* [http://linux.bytesex.org/gdb.html gdb mini intro]
 

2023年10月15日 (日) 19:01時点における最新版

関連記事

この記事では Arch パッケージを作成するときにトレースを取得したり、開発者にソフトウェアのバグを報告するのに役立つデバッグ情報を集める方法を解説します。

通常、実行可能ファイルは、サイズを小さくするために、人間の読める情報が取り除かれています。それだけでなく、そもそも、拡張されたデバッグ情報も通常、実行ファイルに追加されないので、トレースの品質が大幅に劣化します。なので、デバッグ情報のあるトレースを得る前に、デバッグ情報を取り除かずにパッケージを再ビルドする必要があります。

発見したバグを開発者に知らせるときは完全なスタックトレースを使ってください。プログラムの開発に役に立ちます。

パッケージの名前

以下のようなデバッグメッセージが表示される場合:

[...]
Backtrace was generated from '/usr/bin/epiphany'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1241265952 (LWP 12630)]
(no debugging symbols found)
0xb7f25410 in __kernel_vsyscall ()
#0  0xb7f25410 in __kernel_vsyscall ()
#1  0xb741b45b in ?? () from /lib/libpthread.so.0
[...]

?? はデバッグ情報が存在していないために関数を呼び出しているライブラリ・実行可能ファイルがわからないことを意味しています。同じように (no debugging symbols found) と表示されたら、その下に出力されたファイルを確認してください。例えば pacman を使用して確認するには:

$ pacman -Qo /lib/libthread_db.so.1
/lib/libthread_db.so.1 is owned by glibc 2.5-8

パッケージの名前は glibc でバージョンが 2.5-8 とわかりました。デバッグが必要なパッケージの数だけ同じ手順を繰り返してください。

Debuginfod

公式リポジトリ でサポートしているパッケージ [1] では、debuginfod を使って HTTP で直接デバッグ情報を取得することができます。

gdb は、DEBUGINFOD_URLS 環境変数 が設定されている場合に、それらを自動的にダウンロードすることを提案します。 この変数はデフォルトで /etc/profile.d/ に設定されます。

$ gdb application
This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /usr/bin/application
Reading symbols from /home/user/.cache/debuginfod_client/fbaee841e2ed2c11ecbbda26f39eeec1da23d6c3/debuginfo...

debuginfo サポートを有効にしたら、トレースの取得 に進むことができます。

マニュアルダウンロード

zstd のデバッグシンボルといくつかのソースファイルを手動で取得したい場合は、debuginfod-find を利用できます。

$ debuginfod-find debuginfo /usr/bin/zstd
/home/user/.cache/debuginfod_client/70e1b456c5813658df6436a3deb71812e75a0267/debuginfo
$ debuginfod-find source /usr/bin/zstd /usr/src/debug/zstd-1.5.2/programs/fileio.c
/home/user/.cache/debuginfod_client/70e1b456c5813658df6436a3deb71812e75a0267/source##usr##src##debug##zstd-1.5.2##programs##fileio.c

デバッグ情報を手動で取得する

最初に行うことは、再構築が必です または デバッグパッケージのインストール のパッケージの名前を取得することです。

[...]
Backtrace was generated from '/usr/bin/epiphany'

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
[...]

たとえば、トレースからの上記の抜粋の場合、関連するパッケージのパッケージ名は pacman で取得できます。

$ pacman -Qo /lib/libthread_db.so.1
/lib/libthread_db.so.1 is owned by glibc 2.5-8

このパッケージは、バージョン 2.5-8 glibc という名前です。デバッグ情報が必要なパッケージごとにこの手順を繰り返します。

デバッグパッケージをインストールする

ノート: デバッグパッケージは、Arch Linux によって Arch Linux Archive にアーカイブされません。

現在、いくつかのミラーがアクセス可能なリポジトリにデバッグパッケージを配布しています。これらは Arch Linux によって制御されるスポンサー付きミラーであり、デバッグリポジトリへのアクセスが許可されています。

パッケージをインストールするには、リポジトリから直接インストールできます。例えば:

# pacman -U https://geo.mirror.pkgbuild.com/core-debug/os/x86_64/zstd-debug-1.5.2-2-x86_64.pkg.tar.zst
警告: 両方のミラーが同期していない場合、1 つの ミラー からのデバッグパッケージは、別のミラーからの通常のパッケージと互換性がなく、ビルドが一致しません。この場合、異なるミラーからのパッケージを混合することは避けてください (部分アップグレード が発生します) ただし、すべてのリポジトリが debug ミラーを指すようにしてください。
この記事あるいはセクションは 公式リポジトリ と合併することが議論されています。
ノート: 公式リポジトリには、デバッグパッケージを配布する専用ページ (議論: トーク:デバッグ/トレースを取得#mirrors があります。)

もう 1 つのオプションは、pacman 設定にリポジトリを追加することです。

/etc/pacman.conf
# Testing Repositories

[core-testing-debug]
Include = /etc/pacman.d/mirrorlist

[extra-testing-debug]
Include = /etc/pacman.d/mirrorlist

[multilib-testing-debug]
Include = /etc/pacman.d/mirrorlist

# Stable repositories

[core-debug]
Include = /etc/pacman.d/mirrorlist

[extra-debug]
Include = /etc/pacman.d/mirrorlist

[multilib-debug]
Include = /etc/pacman.d/mirrorlist

デバッグパッケージを含むミラーをミラーリストファイルの最初のミラーとして配置します。

/etc/pacman.d/mirrorlist
Server = https://geo.mirror.pkgbuild.com/$repo/os/$arch
...

パッケージを再構築する

デバッグ情報が debuginfod を通じて公開されていない場合 (たとえば、パッケージが AUR から生成されている場合)、ソースから再構築できます。公式リポジトリ のパッケージについては ABS を、AUR のパッケージについては Arch User Repository#ビルドファイルを取得する を参照してください。

ここで、デバッグ目的でしか makepkg を使用しない場合は makepkg のグローバルな設定ファイルを編集してください。そうではない場合は、リビルドしたいパッケージの PKGBUILD だけを修正してください。

コンパイル設定

pacman 4.1 現在、/etc/makepkg.conf のデバッグコンパイルフラグには DEBUG_CFLAGSDEBUG_CXXFLAGS があります。これらを使うには、makepkg オプションの debug を有効化して strip を無効化してください。

OPTIONS+=(debug !strip)

以上の設定で強制的にデバッグシンボルを生成するようにコンパイルされ、実行可能ファイルからシンボルが排除されなくなります。特定のパッケージに適用するときは、PKGBUILD を修正してください:

options=(debug !strip)

もしくは別のパッケージで debugstrip を有効にして、メインのパッケージからデバッグシンボルは取り除き、ソースコードを用意込みでデバッガでステップ実行できるよう、 foo-debug パッケージでデバッグ情報を使うようにすることもできます。

ノート: 新しくコンパイルしたデバッグパッケージをインストールするだけでは不十分です。デバッガは関連するライブラリや実行ファイルと同じビルドからデバッグシンボルが含まれたファイルを確認するためです。再コンパイルしたパッケージを両方ともインストールしてください。Arch ではデバッグシンボルファイルは /usr/lib/debug に、ソースコードは /usr/src/debug にインストールされます。デバッグパッケージについて詳しくは GDB のドキュメント を参照してください。
Glibc

glibc など特定のパッケージは設定に関係なくデバッグ情報が取り除かれます。PKGBUILD の中を確認してください:

strip $STRIP_BINARIES usr/bin/{gencat,getconf,getent,iconv,iconvconfig} \
                      usr/bin/{ldconfig,locale,localedef,nscd,makedb} \
                      usr/bin/{pcprofiledump,pldd,rpcgen,sln,sprof} \
                      usr/lib/getconf/*

strip $STRIP_STATIC usr/lib/*.a

strip $STRIP_SHARED usr/lib/{libanl,libBrokenLocale,libcidn,libcrypt}-*.so \
                    usr/lib/libnss_{compat,db,dns,files,hesiod,nis,nisplus}-*.so \
                    usr/lib/{libdl,libm,libnsl,libresolv,librt,libutil}-*.so \
                    usr/lib/{libmemusage,libpcprofile,libSegFault}.so \
                    usr/lib/{audit,gconv}/*.so

そして必要であれば記述を削除してください。

Clang

Clang をコンパイラとして使用するパッケージは、デバッグフラグ -fvar-tracking-assignments' が処理されないため、debug オプションではビルドされません (例: js78)

影響を受けるパッケージのフラグのみを削除するには、build() 関数の先頭に次のコードを追加します。

build() {
  CFLAGS=${CFLAGS/-fvar-tracking-assignments}
  CXXFLAGS=${CXXFLAGS/-fvar-tracking-assignments}
[...]
LTO

リンク時最適化 (LTO) を使用すると、コンパイル時とデバッガーの両方で、より多くのメモリを使用します [2] [3] アプリケーションによっては、特に Firefox や Qt のような大規模なアプリケーションの場合、使用可能なメモリを超える可能性があります。この問題が発生した場合は、LTO を使用せずにアプリケーションをビルドしてください。

公式リポジトリ内のすべてのパッケージは通常、LTO でビルドされます。

パッケージのビルドとインストール

PKGBUILD のディレクトリから makepkg を使ってソースからパッケージを作成します。多少時間がかかります:

$ makepkg

そしてビルドしたパッケージをインストールしてください:

# pacman -U glibc-2.26-1-x86_64.pkg.tar.gz

トレースの取得

バックトレース (またはスタックトレース) は GNU Debugger gdb で取得できます。次を実行:

# gdb /path/to/file

または:

# gdb
(gdb) exec /path/to/file

既に $PATH 変数に実行可能ファイルが設定されている場合はパスは必要ありません。

次に、gdb の中で、起動したいプログラムに付けたい引数を付けて run を入力します、例:

(gdb) run --no-daemon --verbose

これでファイルの実行が開始されます。バグが再現する操作を行なってください。ログを出力するには以下を入力:

(gdb) set logging file trace.log
(gdb) set logging on

そして:

(gdb) thread apply all bt full

これで gdb が起動したディレクトリの中の trace.log にトレースが出力されます。終了するには、次を入力:

(gdb) set logging off
(gdb) quit
ヒント: Python で書かれているアプリケーションをデバッグするには:
# gdb /usr/bin/python
(gdb) run <python application>

実行中のアプリケーションをデバッグすることもできます、例:

 # gdb --pid=$(pidof firefox)
 (gdb) continue

クラッシュしたアプリケーションをデバッグしたいときは、コアダンプ に対して gdb を起動すると良いでしょう。

参照

翻訳ステータス: このページは en:Debugging/Getting traces の翻訳バージョンです。最後の翻訳日は 2023-10-15 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。