1. ソースファイルを、オブジェクトファイルにコンパイルする
2. オブジェクトファイルおよびライブラリーはリンクされます (以前にコンパイルしたソールも含む)。

手順

1. ソースコードファイルが含まれるディレクトリーに移動します。

2. -c オプションを指定して gcc を実行します。

   $ gcc -c source.c another_source.c

   オブジェクトファイルは、オリジナルのソースコードファイルを反映したファイル名を使用して作成されます。source.c は source.o になります。

   注記

   C++ ソースコードの場合は、標準 C++ ライブラリーの依存関係を処理しやすくするために、gcc コマンドを g++ に置き換えます。

手順

1. オブジェクトコードファイルを含むディレクトリーに移動します。

2. gcc を実行します。

   $ gcc ... objfile.o another_object.o ... -o executable-file

   executable-file という名前の実行ファイルが、指定したオブジェクトファイルとライブラリーをベースに作成されます。

   追加のライブラリーをリンクするには、オブジェクトファイルのリストの前に、必要なオプションを追加します。

   注記

   C++ ソースコードの場合は、標準 C++ ライブラリーの依存関係を処理しやすくするために、gcc コマンドを g++ に置き換えます。

手順

1. hello-c ディレクトリーを作成して、そのディレクトリーに移動します。

   $ mkdir hello-c
   $ cd hello-c

2. 以下の内容を含む hello.c ファイルを作成します。

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. GCC でコードをコンパイルし、リンクします。

   $ gcc hello.c -o helloworld

   これにより、コードがコンパイルされ、オブジェクトファイル hello.o が作成され、オブジェクトファイルから実行ファイル helloworld がリンクされます。

4. 作成された実行可能ファイルを実行します。

   $ ./helloworld
   Hello, World!

手順

1. hello-c ディレクトリーを作成して、そのディレクトリーに移動します。

   $ mkdir hello-c
   $ cd hello-c

2. 以下の内容を含む hello.c ファイルを作成します。

   #include <stdio.h>
   
   int main() {
     printf("Hello, World!\n");
     return 0;
   }

3. GCC でコードをコンパイルします。

   $ gcc -c hello.c

   オブジェクトファイル hello.o が作成されます。

4. オブジェクトファイルから作成した実行可能ファイル helloworld をリンクします。

   $ gcc hello.o -o helloworld

5. 作成された実行可能ファイルを実行します。

   $ ./helloworld
   Hello, World!

手順

1. hello-cpp ディレクトリーを作成して、そのディレクトリーに移動します。

   $ mkdir hello-cpp
   $ cd hello-cpp

2. 以下の内容を含む hello.cpp ファイルを作成します。

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. g++ でコードをコンパイルし、リンクします。

   $ g++ hello.cpp -o helloworld

   これにより、コードがコンパイルされ、オブジェクトファイル hello.o が作成され、オブジェクトファイルから実行ファイル helloworld がリンクされます。

4. 作成された実行可能ファイルを実行します。

   $ ./helloworld
   Hello, World!

手順

1. hello-cpp ディレクトリーを作成して、そのディレクトリーに移動します。

   $ mkdir hello-cpp
   $ cd hello-cpp

2. 以下の内容を含む hello.cpp ファイルを作成します。

   #include <iostream>
   
   int main() {
     std::cout << "Hello, World!\n";
     return 0;
   }

3. g++ でコードをコンパイルします。

   $ g++ -c hello.cpp

   オブジェクトファイル hello.o が作成されます。

4. オブジェクトファイルから作成した実行可能ファイル helloworld をリンクします。

   $ g++ hello.o -o helloworld

5. 作成された実行可能ファイルを実行します。

   $ ./helloworld
   Hello, World!

1. コードが含まれるディレクトリーに移動します。

2. foo ライブラリーのヘッダーで、プログラムソースファイルをコンパイルします。

   $ gcc ... -Iheader_path -c ...

   header_path を、foo ライブラリーのヘッダーファイルを含むディレクトリーのパスに置き換えます。

3. プログラムを foo ライブラリーにリンクします。

   $ gcc ... -Llibrary_path -lfoo ...

   library_path を、libfoo.a ファイルを含むディレクトリーのパスに置き換えます。

4. あとでプログラムを実行するには、次のコマンドを実行します。

   $ ./program

手順

1. ライブラリーソースのディレクトリーに移動します。

2. 位置独立コードオプション -fPIC でオブジェクトファイルに各ソースファイルをコンパイルします。

   $ gcc ... -c -fPIC some_file.c ...

   オブジェクトファイルは、オリジナルのソースコードファイルと同じファイル名ですが、拡張子が .o となります。

3. オブジェクトファイルから共有ライブラリーをリンクします。

   $ gcc -shared -o libfoo.so.x.y -Wl,-soname,libfoo.so.x some_file.o ...

   使用するメジャーバージョン番号は X で、マイナーバージョン番号は Y です。

4. libfoo.so.x.y ファイルを、システムの動的リンカーが検索できる適切な場所にコピーします。Red Hat Enterprise Linux では、ライブラリーのディレクトリーは /usr/lib64 となります。

   # cp libfoo.so.x.y /usr/lib64

   このディレクトリーにあるファイルを操作するには、root パーミッションが必要な点に注意してください。

5. soname メカニズムのシンボリックリンク構造を作成します。

   # ln -s libfoo.so.x.y libfoo.so.x
   # ln -s libfoo.so.x libfoo.so

手順

1. GCC で仲介となるオブジェクトファイルを作成します。

   $ gcc -c source_file.c ...

   必要に応じて、さらにソースファイルを追加します。作成されるオブジェクトファイルはファイル名を共有しますが、拡張子は .o を使用します。

2. binutils パッケージの ar ツールを使用して、オブジェクトファイルを静的ライブラリー (アーカイブ) に変換します。

   $ ar rcs libfoo.a source_file.o ...

   libfoo.a ファイルが作成されます。

3. nm コマンドを使用して、作成されたアーカイブを検証します。

   $ nm libfoo.a

4. 静的ライブラリーファイルを適切なディレクトリーにコピーします。

5. ライブラリーにリンクする場合、GCC は自動的に .a のファイル名の拡張子 (ライブラリーが静的リンクのアーカイブであること) を認識します。

   $ gcc ... -lfoo ...

手順

1. hellomake ディレクトリーを作成して、そのディレクトリーに移動します。

   $ mkdir hellomake
   $ cd hellomake

2. 以下の内容で hello.c ファイルを作成します。

   #include <stdio.h>
   
   int main(int argc, char *argv[]) {
     printf("Hello, World!\n");
     return 0;
   }

3. 以下の内容で Makefile ファイルを作成します。

   CC=gcc
   CFLAGS=-c -Wall
   SOURCE=hello.c
   OBJ=$(SOURCE:.c=.o)
   EXE=hello
   
   all: $(SOURCE) $(EXE)
   
   $(EXE): $(OBJ)
           $(CC) $(OBJ) -o $@
   
   %.o: %.c
           $(CC) $(CFLAGS) $< -o $@
   
   clean:
           rm -rf $(OBJ) $(EXE)

   重要

   Makefile レシピの行は、Tab 文字で開始する必要があります。上記のテキストをドキュメントからコピーする際に、カットアンドペーストのプロセスでは、タブではなくスペースが貼り付けられる場合があります。この場合は、手動で修正してください。

4. make を実行します。

   $ make
   gcc -c -Wall hello.c -o hello.o
   gcc hello.o -o hello

   このコマンドで、実行可能ファイル hello が作成されます。

5. この実行可能ファイル hello を実行します。

   $ ./hello
   Hello, World!

6. Makefile ターゲットの clean を実行して、作成されたファイルを削除します。

   $ make clean
   rm -rf hello.o hello

手順

1. デバッグするアプリケーションまたはライブラリーに割り当てられた GDB を起動します。GDB は、足りないデバッグ情報を自動的に認識し、実行するコマンドを提案します。

   $ gdb -q /bin/ls
   Reading symbols from /bin/ls...Reading symbols from .gnu_debugdata for /usr/bin/ls...(no debugging symbols found)...done.
   (no debugging symbols found)...done.
   Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.30-6.el8.x86_64
   (gdb)

2. GDB を終了します。q と入力して、Enter で確認します。

   (gdb) q

3. GDB が提案するコマンドを実行して、必要な debuginfo パッケージをインストールします。

   # dnf debuginfo-install coreutils-8.30-6.el8.x86_64

   dnf パッケージ管理ツールは、変更の概要を提供し、確認を求め、確認後に必要なファイルをすべてダウンロードしてインストールします。

4. GDB が debuginfo パッケージを提案できない場合は、手動でのアプリケーションまたはライブラリーの debuginfo パッケージの取得 で説明されている手順に従います。

手順

1. アプリケーションまたはライブラリーの実行可能ファイルを検索します。

   1. which コマンドを使用して、アプリケーションファイルを検索します。

      $ which less
      /usr/bin/less

   2. locate コマンドを使用して、ライブラリーファイルを検索します。

      $ locate libz | grep so
      /usr/lib64/libz.so.1
      /usr/lib64/libz.so.1.2.11

      デバッグの元の理由にエラーメッセージが含まれる場合は、ライブラリーのファイル名にエラーメッセージに記載されている番号と同じ追加番号が含まれるものを選択します。疑わしい場合は、ライブラリーファイルの名前に追加の番号が含まれていないものを使用して、残りの手順を試してください。

      注記

      locate コマンドは、mlocate パッケージで提供されます。このパッケージをインストールして、その使用を有効にするには、次のコマンドを実行します。

      # dnf install mlocate
      # updatedb

2. ファイルを提供するパッケージの名前およびバージョンを検索します。

   $ rpm -qf /usr/lib64/libz.so.1.2.7
   zlib-1.2.11-10.el8.x86_64

   この出力では、インストールされているパッケージの詳細が、name:epoch-version.release.architecture 形式で提供されます。

   重要

   この手順では結果が生成されないので、どのパッケージがこのバイナリーファイルを提供しているかは判断できません。次のような状況が考えられます。

   • このファイルは、現在 の設定でパッケージ管理ツールに認識されないパッケージからインストールされます。
   • このファイルは、ローカルにダウンロードして手動でインストールしたパッケージからインストールされます。この場合、適切な debuginfo パッケージを自動的に判断することはできません。
   • パッケージ管理ツールの設定が正しく設定されていません。
   • このファイルは、どのパッケージからもインストールされません。そのような場合は、それぞれの debuginfo パッケージも存在しません。

   これ以降の手順はこの手順によって異なるため、この状況を解決するか、この手順を中止する必要があります。正確なトラブルシューティング手順の説明は、この手順の範囲外です。

3. debuginfo-install ユーティリティーを使用して debuginfo パッケージをインストールします。そのコマンドで、前の手順で確認したパッケージ名およびその他の詳細情報を使用します。

   # debuginfo-install zlib-1.2.11-10.el8.x86_64

1. ps コマンドで、プロセス ID (pid) を検索します。

   $ ps -C program -o pid h
    pid

   program は、ファイル名またはプログラムへのパスに置き換えます。

2. このプロセスに GDB を割り当てます。

   $ gdb -p pid

   pid は、ps の出力にある実際のプロセス ID 番号に置き換えます。

1. GDB コマンド shell を使用して ps コマンドを実行し、プログラムのプロセス ID (pid) を検索します。

   (gdb) shell ps -C program -o pid h
    pid

   program は、ファイル名またはプログラムへのパスに置き換えます。

2. attach コマンドを使用して、GDB をプログラムに割り当てます。

   (gdb) attach pid

   pid は、ps の出力にある実際のプロセス ID の番号に置き換えます。

手順

1. 監視するシステムコールを特定します。

2. strace を起動して、プログラムに割り当てます。

   • 監視するプログラムが実行していない場合は、strace を起動して、プログラム を指定します。

     $ strace -fvttTyy -s 256 -e trace=call program

   • プログラムがすでに実行中の場合は、プロセス id (pid) を検索して、その id に strace を割り当てます。

     $ ps -C program
     (...)
     $ strace -fvttTyy -s 256 -e trace=call -ppid

   • call を、表示するシステムコールに置き換えます。-e trace=call オプションを複数回使用できます。何も指定しない場合、strace はすべてのシステムコールタイプを表示します。詳細は、man ページの strace(1) を参照してください。
   • フォークしたプロセスまたはスレッドを追跡しない場合は、-f オプションを指定しないでください。

3. strace は、アプリケーションで作成したシステムコールとその詳細を表示します。

   ほとんどの場合、システムコールのフィルターが設定されていないと、アプリケーションとそのライブラリーは多数の呼び出しを行い、strace 出力がすぐに表示されます。

4. strace ツールは、プログラムの終了時に、終了します。

   追跡しているプログラムの終了前に監視を中断するには、Ctrl+C を押します。

   • strace でプログラムを起動すると、そのプログラムは strace とともに中断します。
   • 実行中のプログラムに strace を割り当てると、そのプログラムは strace とともに中断します。

5. アプリケーションが実行したシステム呼び出しのリストを分析します。

   • リソースへのアクセスや可用性の問題は、エラーを返す呼び出しとしてログに表示されます。
   • システムコールに渡される値とコールシーケンスのパターンは、アプリケーションの動作の原因に関する洞察を提供します。
   • アプリケーションがクラッシュした場合、重要な情報はおそらくログの最後にあります。
   • 出力には不要な情報が多く含まれています。ただし、目的のシステムコールに対してより正確なフィルターを作成し、この手順を繰り返すことができます。

手順

1. 可能であれば、対象のライブラリーおよび関数を特定します。

2. ltrace を起動し、プログラムに割り当てます。

   • 監視するプログラムが実行していない場合は、ltrace を起動して、プログラム を指定します。

     $ ltrace -f -l library -e function program

   • プログラムがすでに実行中の場合は、プロセス id (pid) を検索して、その id に ltrace を割り当てます。

     $ ps -C program
     (...)
     $ ltrace -f -l library -e function program -ppid

   • -e オプション、-f オプション、および -l オプションを使用して、出力にフィルターを設定します。

     • function として表示される関数の名前を指定します。-e function オプションは複数回使用できます。何も指定しないと、ltrace は全関数への呼び出しを表示します。
     • 関数を指定する代わりに、-l library オプションでライブラリー全体を指定できます。このオプションは、-e function オプションと同じように動作します。
     • フォークしたプロセスまたはスレッドを追跡しない場合は、-f オプションを指定しないでください。

     詳細情報は、man ページの ltrace(1) を参照してください。

3. ltrace は、アプリケーションにより作成されたライブラリーコールを表示します。

   多くの場合は、フィルターが設定されていないと、アプリケーションは多数の呼び出しを作成し、ltrace の出力がすぐに表示されます。

4. ltrace は、プログラムが終了すると終了します。

   追跡しているプログラムの終了前に監視を中断するには、ctrl+C を押します。

   • ltrace でプログラムを起動した場合には、プログラムは ltrace と共に中断します。
   • 実行中のプログラムに ltrace を割り当てると、プログラムは ltrace と共に終了します。

5. アプリケーションが実行したライブラリーコールのリストを分析します。

   • アプリケーションがクラッシュした場合、重要な情報はおそらくログの最後にあります。
   • 出力には不要な情報が多く含まれています。ただし、より正確なフィルターを作成して、手順を繰り返すことができます。

手順

1. 監視するプロセスのプロセス ID (pid) を検索します。

   $ ps -aux

2. strace.stp スクリプトで SystemTap を実行します。

   # stap /usr/share/systemtap/examples/process/strace.stp -x pid

   pid の値は、プロセス ID です。

   スクリプトはカーネルモジュールにコンパイルされ、それが読み込まれます。これにより、コマンドの入力から出力の取得までにわずかな遅延が生じます。

3. プロセスでシステム呼び出しが実行されると、呼び出し名とパラメーターがターミナルに出力されます。
4. プロセスが終了した場合、または Ctrl+C を押すと、スクリプトは終了します。

手順

1. キャッチポイントを設定します。

   (gdb) catch syscall syscall-name

   catch syscall コマンドは、プログラムがシステムコールを実行する際に実行を停止する特別なブレークポイントを設定します。

   syscall-name オプションは、コールの名前を指定します。様々なシステム呼び出しに対して複数のキャッチポイントを指定することができます。syscall-name オプションを指定しないと、システムコールで GDB が停止します。

2. プログラムの実行を開始します。

   • プログラムにより、実行が開始していない場合は開始します。

     (gdb) r

   • プログラムの実行が停止した場合は、再開します。

     (gdb) c

3. GDB は、プログラムが指定のシステムコールを実行した後に実行を停止します。

手順

1. キャッチポイントを設定します。

   (gdb) catch signal signal-type

   catch signal コマンドは、プログラムがシステムコールを受けたときに実行を停止する特別なブレークポイントを設定します。signal-type オプションは、シグナルのタイプを指定します。すべてのシグナルを取得するには、特別な値 all を使用します。

2. プログラムを実行します。

   • プログラムにより、実行が開始していない場合は開始します。

     (gdb) r

   • プログラムの実行が停止した場合は、再開します。

     (gdb) c

3. GDB は、プログラムが指定のシグナルを受けると実行を停止します。

手順

1. コアダンプを有効にするには、/etc/systemd/system.conf ファイルに以下の行が含まれていることを確認します。

   DumpCore=yes
   DefaultLimitCORE=infinity

   これらの設定が以前に存在したかどうか、以前の値が何であったかを説明するコメントを追加することもできます。これにより、必要に応じて、この変更を後で元に戻すことができます。コメントは、# 文字で始まる行です。

   ファイルを変更するには、管理者レベルのアクセスが必要です。

2. 新しい設定を適用します。

   # systemctl daemon-reexec

3. コアダンプサイズの制限を削除します。

   # ulimit -c unlimited

   この変更を元に戻すには、unlimited ではなく、0 を指定してコマンドを実行します。

4. システム情報を収集する sosreport ユーティリティーを提供する sos パッケージをインストールします。

   # dnf install sos

5. アプリケーションがクラッシュすると、コアダンプが生成され、systemd-coredump により処理されます。

6. SOS レポートを作成して、システムに関する追加情報を提供します。

   # sosreport

   これにより、設定ファイルのコピーなど、システムに関する情報が含まれる .tar アーカイブが作成されます。

7. コアダンプを探してエクスポートします。

   $ coredumpctl list executable-name
   $ coredumpctl dump executable-name > /path/to/file-for-export

   アプリケーションが複数回クラッシュした場合、最初のコマンドの出力には、取得されたコアダンプがさらにリスト表示されます。その場合、2 番目のコマンドに対して、他の情報を使用してより正確なクエリーを作成します。詳細は、man ページ coredumpctl(1) を参照してください。

8. デバッグを行うコンピューターに、コアダンプと SOS レポートを移動します。既知の場合は、実行ファイルも転送します。

   重要

   実行可能ファイルが不明な場合は、コアファイルのその後の分析で特定します。

9. オプション: コアダンプと SOS レポートに移動後に削除して、ディスク領域を解放します。

手順

1. クラッシュが発生した実行ファイルを特定するには、コアダンプファイルを指定して eu-unstrip コマンドを実行します。

   $ eu-unstrip -n --core=./core.9814
   0x400000+0x207000 2818b2009547f780a5639c904cded443e564973e@0x400284 /usr/bin/sleep /usr/lib/debug/bin/sleep.debug [exe]
   0x7fff26fff000+0x1000 1e2a683b7d877576970e4275d41a6aaec280795e@0x7fff26fff340 . - linux-vdso.so.1
   0x35e7e00000+0x3b6000 374add1ead31ccb449779bc7ee7877de3377e5ad@0x35e7e00280 /usr/lib64/libc-2.14.90.so /usr/lib/debug/lib64/libc-2.14.90.so.debug libc.so.6
   0x35e7a00000+0x224000 3ed9e61c2b7e707ce244816335776afa2ad0307d@0x35e7a001d8 /usr/lib64/ld-2.14.90.so /usr/lib/debug/lib64/ld-2.14.90.so.debug ld-linux-x86-64.so.2

   出力には、行ごとに各モジュールの詳細が、スペースで区切られます。情報は以下の順序でリスト表示されます。

   1. モジュールがマッピングされているメモリーアドレス
   2. モジュールのビルド ID、およびメモリー内の場所
   3. モジュールの実行ファイル名 - 不明の場合は -、モジュールがファイルから読み込まれていない場合は . と表示されます。
   4. デバッグ情報のソース - 使用可能な場合はファイル名が表示されます。実行ファイル自体に含まれている場合は .、存在しない場合は - と表示されます。
   5. 主要なモジュールの共有ライブラリー名 (soname) または [exe]

   この例では、重要な詳細は、テキスト [exe] を含む行のファイル名 /usr/bin/sleep と、ビルド ID 2818b2009547f780a5639c904cded443e564973e です。この情報を使用して、コアダンプの分析に必要な実行可能ファイルを特定できます。

2. クラッシュした実行可能ファイルを取得します。

   • 可能であれば、クラッシュが発生したシステムからコピーします。コアファイルから抽出したファイル名を使用します。

   • システムで同じ実行ファイルを使用することもできます。Red Hat Enterprise Linux にビルドされた実行ファイルはそれぞれ、固有の build-id 値を持つメモが含まれています。関連する、ローカルで利用可能な実行ファイルの build-id を特定します。

     $ eu-readelf -n executable_file

     この情報を使用して、リモートシステムの実行可能ファイルをローカルコピーと一致させます。ローカルファイルの build-id とコアダンプに記載されている build-id は一致する必要があります。

   • 最後に、アプリケーションが RPM パッケージからインストールされている場合は、パッケージから実行ファイルを取得できます。sosreport 出力を使用して、必要なパッケージの正確なバージョンを確認します。
3. 実行可能ファイルで使用する共有ライブラリーを取得します。実行ファイルと同じ手順を使用します。
4. アプリケーションがパッケージとして配布されている場合は、GDB で実行ファイルを読み込み、足りない debuginfo パッケージに関するヒントを表示します。詳細は 「GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得」 を参照してください。

5. コアファイルを詳細に調べるには、GDB で実行ファイルとコアダンプファイルを読み込みます。

   $ gdb -e executable_file -c core_file

   不足しているファイルとデバッグ情報に関する追加のメッセージは、デバッグセッションで不足しているものを特定するのに役に立ちます。必要に応じて直前の手順に戻ります。

   アプリケーションのデバッグ情報がパッケージではなくファイルとして利用できる場合は、symbol-file コマンドを使用してこのファイルを GDB に読み込みます。

   (gdb) symbol-file program.debug

   program.debug は、実際のファイル名に置き換えます。

   注記

   コアダンプに含まれるすべての実行可能ファイルのデバッグ情報をインストールする必要はない場合があります。これらの実行可能ファイルのほとんどは、アプリケーションコードで使用されるライブラリーです。これらのライブラリーが分析中の問題の直接原因でない可能性があるので、ライブラリーのデバッグ情報を含める必要はありません。

6. GDB コマンドを使用して、クラッシュした時点のアプリケーションの状態を検査します。GDB を使用したアプリケーションの内部状況の検証 を参照してください。

   注記

   コアファイルを分析する場合に、GDB が実行中のプロセスに割り当てられる訳ではありません。実行を制御するコマンドは影響を受けません。

手順

1. 実行ファイル名の既知の部分に基づいて、ハングしたプロセスの PID を検索します。

   $ pgrep -a executable-name-fragment

   このコマンドは、フォームの行を出力します。

   PID command-line

   command-line 値を使用して、PID が目的のプロセスに属することを確認します。

   以下に例を示します。

   $ pgrep -a bc
   5459 bc

2. 中断シグナルをプロセスに送信します。

   # kill -ABRT PID

3. コアが coredumpctl で取得されていることを確認します。

   $ coredumpctl list PID

   以下に例を示します。

   $ coredumpctl list 5459
   TIME                            PID   UID   GID SIG COREFILE  EXE
   Thu 2019-11-07 15:14:46 CET    5459  1000  1000   6 present   /usr/bin/bc

4. 必要に応じて、コアファイルをさらに検証または使用します。

   PID と他の値でコアダンプを指定できます。詳細は、man ページの coredumpctl(1) を参照してください。

   • コアファイルの詳細を表示します。

     $ coredumpctl info PID

   • GDB デバッガーでコアファイルを読み込むには、次のコマンドを実行します。

     $ coredumpctl debug PID

     デバッグ情報の可用性によっては、GDB は次のようなコマンドを実行するコマンドを提案します。

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-5.el8.x86_64

     このプロセスの詳細は、GDB を使用したアプリケーションまたはライブラリーの debuginfo パッケージの取得 を参照してください。

   • その後の処理を別の場所でするためにコアファイルをエクスポートするには、次のコマンドを実行します。

     $ coredumpctl dump PID > /path/to/file_for_export

     /path/to/file_for_export を、コアダンプを配置するファイルに置き換えます。

手順

1. プロセス ID (pid) を検索します。ps、pgrep、top などのツールを使用します。

   $ ps -C some-program

2. このプロセスのメモリーをダンプします。

   $ gcore -o filename pid

   これでファイル filename が作成され、その中にプロセスメモリーがダンプされます。メモリーをダンプしている間は、プロセスの実行は停止します。

3. コアダンプが終了すると、プロセスは通常の実行を再開します。

4. SOS レポートを作成して、システムに関する追加情報を提供します。

   # sosreport

   これにより、設定ファイルのコピーなど、システムに関する情報が含まれる .tar アーカイブが作成されます。

5. デバッグを行うコンピューターに、プログラムの実行ファイル、コアダンプ、および SOS レポートを移動します。
6. オプション: コアダンプと SOS レポートに移動後に削除して、ディスク領域を解放します。

手順

1. /proc/PID/coredump_filter ファイルの設定を無視するように GDB を設定します。

   (gdb) set use-coredump-filter off

2. メモリーページのフラグ VM_DONTDUMP を無視するように GDB を設定します。

   (gdb) set dump-excluded-mappings on

3. メモリーをダンプします。

   (gdb) gcore core-file

   core-file を、メモリーをダンプするファイルの名前に置き換えます。

手順

1. カスタマーポータルの認証情報を使用して Red Hat コンテナーレジストリー にアクセスします。

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. root で適切なコマンドを実行して、必要なコンテナーイメージをプルします。

   # podman pull registry.redhat.io/rhel9/gcc-toolset-13-toolchain

   注記

   root 以外のユーザーとしてコンテナーを操作するようにシステムをセットアップすることもできます。詳細は、ルートレスコンテナーのセットアップ を参照してください。

3. オプション: ローカルシステムにあるすべてのコンテナーイメージをリスト表示するコマンドを実行して、プルが正常に完了したことを確認します。

   # podman images

4. コンテナー内で bash シェルを起動して、コンテナーを実行します。

   # podman run -it image_name /bin/bash

   -i オプションは対話式のセッションを作成します。このオプションを指定しないと、シェルが開き、即座に終了します。

   -t オプションは端末セッションを開きます。このオプションがないと、シェルに何も入力できません。

手順

1. カスタマーポータルの認証情報を使用して Red Hat コンテナーレジストリーにアクセスします。

   $ podman login registry.redhat.io
   Username: username
   Password: ********

2. root でコンテナーイメージをプルします。

   # podman pull registry.redhat.io/rhel9/gcc-toolset-13-toolchain

3. root で対話式シェルを使用してコンテナーイメージを起動します。

   # podman run -it registry.redhat.io/rhel9/gcc-toolset-13-toolchain /bin/bash

4. GCC Toolset ツールを想定どおりに実行します。たとえば、gcc コンパイラーのバージョンを確認するには、次のコマンドを実行します。

   bash-4.4$ gcc -v
   ...
   gcc version 13.1.1 20231102 (Red Hat 13.1.1-4) (GCC)

5. コンテナーで提供されるパッケージのリストを表示するには、以下を実行します。

   bash-4.4$ rpm -qa