Developing C and C++ applications in RHEL 10

1. Source files are compiled to object files.
2. Object files and libraries are linked (including the previously compiled sources).

Procedure

1. In Terminal, open to the directory containing the source code file(s).

2. Run gcc with the -c option:

   $ gcc -c source.c another_source.c

   Copy to Clipboard Toggle word wrap

   Object files are created, with their file names reflecting the original source code files: source.c results in source.o.

   Note

   With C++ source code, replace the gcc command with g++ for convenient handling of C++ Standard Library dependencies.

Procedure

1. Compile and link your code with the -g option to generate debugging information:

   $ gcc ... -g ...

   Copy to Clipboard Toggle word wrap

2. Optional: Set the optimization level to -Og:

   $ gcc ... -g -Og ...

   Copy to Clipboard Toggle word wrap

   Compiler optimizations can make executable code hard to relate to the source code. The -Og option optimizes the code without interfering with debugging. However, be aware that changing optimization levels can alter the program’s behavior.

3. Optional: Use -g for moderate debugging information, or -g3 to include macro definitions:

   $ gcc ... -g3 ...

   Copy to Clipboard Toggle word wrap

Procedure

1. Change to the directory containing the object code file(s).

2. Run gcc:

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

   Copy to Clipboard Toggle word wrap

   An executable file named executable-file is created from the supplied object files and libraries. To link additional libraries, add the required options after the list of object files.

   For more information, see Using libraries with GCC.

   Note

   With C++ source code, replace the gcc command with g++ for convenient handling of C++ Standard Library dependencies.

Procedure

1. Create a directory hello-c:

   $ mkdir hello-c

   Copy to Clipboard Toggle word wrap

2. Change to the created directory:

   $ cd hello-c

   Copy to Clipboard Toggle word wrap

3. Create file hello.c with the following contents:

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

   Copy to Clipboard Toggle word wrap

4. Compile and link the code with GCC:

   $ gcc hello.c -o helloworld

   Copy to Clipboard Toggle word wrap

   This compiles the code, creates the object file hello.o, and links the executable file helloworld from the object file.

5. Run the resulting executable file:

   $ ./helloworld

   Copy to Clipboard Toggle word wrap

   Hello, World!

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a directory hello-c:

   $ mkdir hello-c

   Copy to Clipboard Toggle word wrap

2. Change to the created directory:

   $ cd hello-c

   Copy to Clipboard Toggle word wrap

3. Create file hello.c with the following contents:

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

   Copy to Clipboard Toggle word wrap

4. Compile the code with GCC:

   $ gcc -c hello.c

   Copy to Clipboard Toggle word wrap

   The object file hello.o is created.

5. Link an executable file helloworld from the object file:

   $ gcc hello.o -o helloworld

   Copy to Clipboard Toggle word wrap

6. Run the resulting executable file:

   $ ./helloworld
   Hello, World!

   Copy to Clipboard Toggle word wrap

7. Optional: Change back to the parent directory:

   $ cd ..

   Copy to Clipboard Toggle word wrap

8. Optional: Remove the hello-c directory:

   $ rm -r hello-c

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a directory hello-cpp:

   $ mkdir hello-cpp

   Copy to Clipboard Toggle word wrap

2. Change to the created directory:

   $ cd hello-cpp

   Copy to Clipboard Toggle word wrap

3. Create file hello.cpp with the following contents:

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

   Copy to Clipboard Toggle word wrap

4. Compile and link the code with g++:

   $ g++ hello.cpp -o helloworld

   Copy to Clipboard Toggle word wrap

   This compiles the code, creates the object file hello.o, and links the executable file helloworld from the object file.

5. Run the resulting executable file:

   $ ./helloworld

   Copy to Clipboard Toggle word wrap

   Hello, World!

   Copy to Clipboard Toggle word wrap

6. Optional: Change back to the parent directory:

   $ cd ..

   Copy to Clipboard Toggle word wrap

7. Optional: Remove the hello-cpp directory:

   $ rm -r hello-cpp

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a directory hello-cpp:

   $ mkdir hello-cpp

   Copy to Clipboard Toggle word wrap

2. Change to the created directory:

   $ cd hello-cpp

   Copy to Clipboard Toggle word wrap

3. Create file hello.cpp with the following contents:

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

   Copy to Clipboard Toggle word wrap

4. Compile the code with g++:

   $ g++ -c hello.cpp

   Copy to Clipboard Toggle word wrap

   The object file hello.o is created.

5. Link an executable file helloworld from the object file:

   $ g++ hello.o -o helloworld

   Copy to Clipboard Toggle word wrap

6. Run the resulting executable file:

   $ ./helloworld

   Copy to Clipboard Toggle word wrap

   Hello, World!

   Copy to Clipboard Toggle word wrap

7. Optional: Change back to the parent directory:

   $ cd ..

   Copy to Clipboard Toggle word wrap

8. Optional: Remove the hello-cpp directory:

   $ rm -r hello-cpp

   Copy to Clipboard Toggle word wrap

Procedure

1. Change to the directory with library sources.

2. Compile each source file to an object file with the Position independent code option -fPIC:

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

   Copy to Clipboard Toggle word wrap

   The object files have the same file names as the original source code files, but their extension is .o.

3. Link the shared library from the object files:

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

   Copy to Clipboard Toggle word wrap

   The used major version number is X and minor version number Y.

4. Copy the libfoo.so.x.y file to an appropriate location, where the system’s dynamic linker can find it. On Red Hat Enterprise Linux, the directory for libraries is /usr/lib64:

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

   Copy to Clipboard Toggle word wrap

   Note that you need root permissions to manipulate files in this directory.

5. Create the symlink for the soname:

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

   Copy to Clipboard Toggle word wrap

6. Create the symlink for the linker name:

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

   Copy to Clipboard Toggle word wrap

Procedure

1. Create intermediate object files with GCC.

   $ gcc -c source_file.c ...

   Copy to Clipboard Toggle word wrap

   Append more source files if required. The resulting object files share the file name but use the .o file name extension.

2. Turn the object files into a static library (archive) using the ar tool from the binutils package.

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

   Copy to Clipboard Toggle word wrap

   File libfoo.a is created.

3. Use the nm command to inspect the resulting archive:

   $ nm libfoo.a

   Copy to Clipboard Toggle word wrap
4. Copy the static library file to the appropriate directory.

5. When linking against the library, GCC will automatically recognize from the .a file name extension that the library is an archive for static linking.

   $ gcc ... -lfoo ...

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a directory hellomake:

   $ mkdir hellomake

   Copy to Clipboard Toggle word wrap

2. Change to the created directory:

   $ cd hellomake

   Copy to Clipboard Toggle word wrap

3. Create a file hello.c with the following contents:

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

   Copy to Clipboard Toggle word wrap

4. Create a file Makefile with the following contents:

   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)

   Copy to Clipboard Toggle word wrap
   Important

   The Makefile recipe lines must start with the tab character! When copying the text above from the documentation, the cut-and-paste process might paste spaces instead of tabs. If this happens, correct the issue manually.

5. Run make:

   $ make

   Copy to Clipboard Toggle word wrap

   gcc -c -Wall hello.c -o hello.o
   gcc hello.o -o hello

   Copy to Clipboard Toggle word wrap

   This creates an executable file hello.

6. Run the executable file hello:

   $ ./hello

   Copy to Clipboard Toggle word wrap

   Hello, World!

   Copy to Clipboard Toggle word wrap

7. Run the Makefile target clean to remove the created files:

   $ make clean

   Copy to Clipboard Toggle word wrap

   rm -rf hello.o hello

   Copy to Clipboard Toggle word wrap

Procedure

1. Compile and link your code with the -g option to generate debugging information:

   $ gcc ... -g ...

   Copy to Clipboard Toggle word wrap

2. Optional: Set the optimization level to -Og:

   $ gcc ... -g -Og ...

   Copy to Clipboard Toggle word wrap

   Compiler optimizations can make executable code hard to relate to the source code. The -Og option optimizes the code without interfering with debugging. However, be aware that changing optimization levels can alter the program’s behavior.

3. Optional: Use -g for moderate debugging information, or -g3 to include macro definitions:

   $ gcc ... -g3 ...

   Copy to Clipboard Toggle word wrap

Procedure

1. Start GDB attached to the application or library you want to debug. GDB automatically recognizes missing debugging information and suggests a command to run.

   $ gdb -q /bin/ls

   Copy to Clipboard Toggle word wrap

   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-9.5-6.el10.x86_64
   (gdb)

   Copy to Clipboard Toggle word wrap

2. Exit GDB: type q and confirm with Enter.

   (gdb) q

   Copy to Clipboard Toggle word wrap

3. Run the command suggested by GDB to install the required debuginfo packages:

   # dnf debuginfo-install coreutils-9.5-6.el10.x86_64

   Copy to Clipboard Toggle word wrap

   The dnf package management tool provides a summary of the changes, asks for confirmation and once you confirm, downloads and installs all the necessary files.

4. In case GDB is not able to suggest the debuginfo package, follow the procedure described in

   • Getting debuginfo packages for an application or library manually.

Procedure

1. Find the executable file of the application or library.

   1. Use the which command to find the application file.

      $ which less

      Copy to Clipboard Toggle word wrap

      /usr/bin/less

      Copy to Clipboard Toggle word wrap

   2. Use the locate command to find the library file.

      $ locate libz | grep so

      Copy to Clipboard Toggle word wrap

      /usr/lib64/libz.so.1
      /usr/lib64/libz.so.1.2.11

      Copy to Clipboard Toggle word wrap

      If the original reasons for debugging include error messages, pick the result where the library has the same additional numbers in its file name as those mentioned in the error messages. If in doubt, try following the rest of the procedure with the result where the library file name includes no additional numbers.

      Note

      The locate command is provided by the mlocate package. To install it and enable its use:

      # dnf install mlocate

      Copy to Clipboard Toggle word wrap

      1. Update the database:

         # updatedb

         Copy to Clipboard Toggle word wrap

2. Search for a name and version of the package that provided the file:

   $ rpm -qf /usr/lib64/libz.so.1.3.1.zlib-ng

   Copy to Clipboard Toggle word wrap

   zlib-ng-compat-2.2.3-1.el10.x86_64

   Copy to Clipboard Toggle word wrap

   The output provides details for the installed package in the name:epoch-version.release.architecture format.

   Important

   If this step does not produce any results, it is not possible to determine which package provided the binary file. There are several possible cases:

   • The file is installed from a package which is not known to package management tools in their current configuration.
   • The file is installed from a locally downloaded and manually installed package. Determining a suitable debuginfo package automatically is impossible in that case.
   • Your package management tools are misconfigured.
   • The file is not installed from any package. In such a case, no corresponding debuginfo package exists.

   Because further steps depend on this one, you must resolve this situation or stop this procedure. Describing the exact troubleshooting steps is beyond the scope of this procedure.

3. Install the debuginfo packages using the dnf debuginfo-install utility. In the command, use the package name and other details you determined during the previous step:

   # dnf debuginfo-install zlib-ng-compat-2.2.3-1.el10.x86_64

   Copy to Clipboard Toggle word wrap

Procedure

1. Identify the system calls to monitor.

   • Start strace and attach it to the program.

     • If the program you want to monitor is not running, start strace and specify the program:

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

       Copy to Clipboard Toggle word wrap

     • If the program is already running, find its process id (pid):

       $ ps -C program

       Copy to Clipboard Toggle word wrap

     • Attach strace to the process:

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

       Copy to Clipboard Toggle word wrap
   • Replace call with the system calls to be displayed. You can use the -e trace=call option multiple times. If left out, strace will display all system call types. See the strace(1) manual page for more information.
   • If you do not want to trace any forked processes or threads, omit the -f option.

2. The strace tool displays the system calls made by the application and their details.

   In most cases, an application and its libraries make a large number of calls and strace output displays immediately, if no filter for system calls is set.

3. The strace tool exits when the program exits.

   To terminate the monitoring before the traced program exits, press Ctrl+C.

   • If strace started the program, the program terminates together with strace.
   • If you attached strace to an already running program, the program terminates together with strace.

4. Analyze the list of system calls done by the application.

   • Problems with resource access or availability are present in the log as calls returning errors.
   • Values passed to the system calls and patterns of call sequences provide insight into the causes of the application’s behaviour.
   • If the application crashes, the important information is probably at the end of log.

   • The output contains a large amount of unnecessary information. However, you can construct a more precise filter for the system calls of interest and repeat the procedure.

     Note

     It is advantageous to both see the output and save it to a file. Use the tee command to achieve this:

     $ strace ... |& tee your_log_file.log

     Copy to Clipboard Toggle word wrap

Procedure

1. Identify the libraries and functions of interest, if possible.

2. Start ltrace and attach it to the program.

   Note

   In Red Hat Enterprise Linux 10, a known issue prevents ltrace from tracing system executable files. This limitation does not apply to executable files built by users.

   • If the program you want to monitor is not running, start ltrace and specify program:

     $ ltrace -f -l library -e function program

     Copy to Clipboard Toggle word wrap

   • If the program is already running, find its process id (pid):

     $ ps -C program

     Copy to Clipboard Toggle word wrap

   • Attach ltrace to the process:

     $ ltrace -f -l library -e function -ppid program

     Copy to Clipboard Toggle word wrap

   • Use the -e, -f and -l options to filter the output:

     • Supply the function names to be displayed as function. The -e function option can be used multiple times. If left out, ltrace displays calls to all functions.
     • Instead of specifying functions, you can specify whole libraries with the -l library option. This option behaves similarly to the -e function option.
     • If you do not want to trace any forked processes or threads, omit the -f option.

     See the ltrace(1)_ manual page for more information.

3. ltrace displays the library calls made by the application.

   In most cases, an application makes a large number of calls and ltrace output displays immediately, if no filter is set.

4. ltrace exits when the program exits.

   To terminate the monitoring before the traced program exits, press ctrl+C.

   • If ltrace started the program, the program terminates together with ltrace.
   • If you attached ltrace to an already running program, the program terminates together with ltrace.
5. Stop ltrace by pressing Ctrl+C.

6. Analyze the list of library calls done by the application.

   • If the application crashes, the important information is probably at the end of log.

   • The output contains a large amount of unnecessary information. However, you can construct a more precise filter and repeat the procedure.

     Note

     It is advantageous to both see the output and save it to a file. Use the tee command to achieve this:

     $ ltrace ... |& tee your_log_file.log

     Copy to Clipboard Toggle word wrap

Procedure

1. Find the process ID (pid) of the process you want to monitor:

   $ ps -aux

   Copy to Clipboard Toggle word wrap

2. Run SystemTap with the strace.stp script:

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

   Copy to Clipboard Toggle word wrap

   The value of pid is the process id.

   The script is compiled to a kernel module, which is then loaded. This introduces a slight delay between entering the command and getting the output.

3. When the process performs a system call, the call name and its parameters are printed to the terminal.
4. The script exits when the process terminates, or when you press Ctrl+C.

Procedure

1. Set the catchpoint:

   (gdb) catch syscall syscall-name

   Copy to Clipboard Toggle word wrap

   The command catch syscall sets a special type of breakpoint that halts execution when the program performs a system call.

   The syscall-name option specifies the name of the call. You can specify multiple catchpoints for various system calls. Leaving out the syscall-name option causes GDB to stop on any system call.

2. Start execution of the program.

   • If the program has not started execution, start it:

     (gdb) r

     Copy to Clipboard Toggle word wrap

   • If the program execution is halted, resume it:

     (gdb) c

     Copy to Clipboard Toggle word wrap
3. GDB halts execution after the program performs any specified system call.
4. Use further GDB commands to examine the program state and advance execution, according to the particular situation.

5. To exit the GDB debugging session:

   (gdb) q

   Copy to Clipboard Toggle word wrap

Procedure

1. Set the catchpoint:

   (gdb) catch signal signal-type

   Copy to Clipboard Toggle word wrap

   The command catch signal sets a special type of a breakpoint that halts execution when a signal is received by the program. The signal-type option specifies the type of the signal. Use the special value 'all' to catch all signals.

2. Let the program run.

   • If the program has not started execution, start it:

     (gdb) r

     Copy to Clipboard Toggle word wrap

   • If the program execution is halted, resume it:

     (gdb) c

     Copy to Clipboard Toggle word wrap
3. GDB halts execution after the program receives any specified signal.
4. Continue by debugging the program code handling the signal, or resume execution with the knowledge of the signal being received.

5. Later, to exit the GDB debugging session:

   (gdb) q

   Copy to Clipboard Toggle word wrap

Procedure

1. To enable core dumps, ensure that the /etc/systemd/system.conf file contains the following lines:

   DumpCore=yes
   DefaultLimitCORE=infinity

   Copy to Clipboard Toggle word wrap

   You can also add comments describing if these settings were previously present, and what the previous values were. This will enable you to reverse these changes later, if needed. Comments are lines starting with the # character.

   Changing the file requires administrator level access.

2. Apply the new configuration:

   # systemctl daemon-reexec

   Copy to Clipboard Toggle word wrap

3. Remove the limits for core dump sizes:

   # ulimit -c unlimited

   Copy to Clipboard Toggle word wrap

   To reverse this change, run the command with value 0 instead of unlimited.

4. Install the sos package which provides the sosreport utility for collecting system information:

   # dnf install sos

   Copy to Clipboard Toggle word wrap
5. When an application crashes, a core dump is generated and handled by systemd-coredump.

6. Create an SOS report to provide additional information about the system:

   # sosreport

   Copy to Clipboard Toggle word wrap

   This creates a .tar archive containing information about your system, such as copies of configuration files.

7. Locate the core dump:

   $ coredumpctl list executable-name

   Copy to Clipboard Toggle word wrap

8. Export the core dump:

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

   Copy to Clipboard Toggle word wrap

   If the application crashed multiple times, output of the first command lists more captured core dumps. In that case, construct for the second command a more precise query by using the other information. See the coredumpctl(1) manual page for details.

9. Transfer the core dump and the SOS report to the computer where the debugging will take place. Transfer the executable file, too, if it is known.

   Important

   When the executable file is not known, subsequent analysis of the core file identifies it.

10. Optional: Remove the core dump and SOS report after transferring them, to free up disk space.

Procedure

1. To identify the executable file where the crash occurred, run the eu-unstrip command with the core dump file:

   $ eu-unstrip -n --core=./core.9814

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   The output contains details for each module on a line, separated by spaces. The information is listed in this order:

   1. The memory address where the module was mapped
   2. The build-id of the module and where in the memory it was found
   3. The module’s executable file name, displayed as - when unknown, or as . when the module has not been loaded from a file
   4. The source of debugging information, displayed as a file name when available, as . when contained in the executable file itself, or as - when not present at all
   5. The shared library name (soname) or [exe] for the main module

   In this example, the important details are the file name /usr/bin/sleep and the build-id 2818b2009547f780a5639c904cded443e564973e on the line containing the text [exe]. With this information, you can identify the executable file required for analyzing the core dump.

2. Get the executable file that crashed.

   • If possible, copy it from the system where the crash occurred. Use the file name extracted from the core file.

   • You can also use an identical executable file on your system. Each executable file built on Red Hat Enterprise Linux contains a note with a unique build-id value. Determine the build-id of the relevant locally available executable files:

     $ eu-readelf -n executable_file

     Copy to Clipboard Toggle word wrap

     Use this information to match the executable file on the remote system with your local copy. The build-id of the local file and build-id listed in the core dump must match.

   • Finally, if the application is installed from an RPM package, you can get the executable file from the package. Use the sosreport output to find the exact version of the package required.
3. Get the shared libraries used by the executable file. Use the same steps as for the executable file.
4. If the application is distributed as a package, load the executable file in GDB, to display hints for missing debuginfo packages. For more details, see Getting debuginfo packages for an application or library using GDB.

5. To examine the core file in detail, load the executable file and core dump file with GDB:

   $ gdb -e executable_file -c core_file

   Copy to Clipboard Toggle word wrap

   Further messages about missing files and debugging information help you identify what is missing for the debugging session. Return to the previous step if needed.

   If the application’s debugging information is available as a file instead of as a package, load this file in GDB with the symbol-file command:

   (gdb) symbol-file program.debug

   Copy to Clipboard Toggle word wrap

   Replace program.debug with the actual file name.

   Note

   It might not be necessary to install the debugging information for all executable files contained in the core dump. Most of these executable files are libraries used by the application code. These libraries might not directly contribute to the problem you are analyzing, and you do not need to include debugging information for them.

6. Use the GDB commands to inspect the state of the application at the moment it crashed. See Inspecting Application Internal State with GDB.

   Note

   When analyzing a core file, GDB is not attached to a running process. Commands for controlling execution have no effect.

7. To see only the stack of the application at the moment it terminated, open the core file with the eu-stack utility:

   $ eu-stack --core core-file

   Copy to Clipboard Toggle word wrap

   This will display listing of the application’s stack.

Procedure

1. Find the PID of the hung process, based on a known part of the executable file name:

   $ pgrep -a executable-name-fragment

   Copy to Clipboard Toggle word wrap

   This command will output a line in the form

   PID command-line

   Copy to Clipboard Toggle word wrap

   Use the command-line value to verify that the PID belongs to the intended process.

   For example:

   $ pgrep -a bc

   Copy to Clipboard Toggle word wrap

   5459 bc

   Copy to Clipboard Toggle word wrap

2. Send an abort signal to the process:

   # kill -ABRT PID

   Copy to Clipboard Toggle word wrap

3. Verify that the core has been captured by coredumpctl:

   $ coredumpctl list PID

   Copy to Clipboard Toggle word wrap

   For example:

   $ coredumpctl list 5459

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

4. Further examine or use the core file as needed.

   You can specify the core dump by PID and other values. See the coredumpctl(1) manual page for further details.

   Next steps

   • To show details of the core file, run:

     $ coredumpctl info PID

     Copy to Clipboard Toggle word wrap

   • To load the core file in the GDB debugger, run:

     $ coredumpctl debug PID

     Copy to Clipboard Toggle word wrap

     Depending on the availability of debugging information, GDB might suggest commands to run, such as:

     Missing separate debuginfos, use: dnf debuginfo-install bc-1.07.1-23.el10.x86_64

     Copy to Clipboard Toggle word wrap

     For more details on this process, see Getting debuginfo packages for an application or library using GDB.

   • To export the core file for further processing elsewhere, run:

     $ coredumpctl dump PID > /path/to/file_for_export

     Copy to Clipboard Toggle word wrap

   • Replace /path/to/file_for_export with the file where you want to put the core dump.

     $ coredumpctl dump PID > /path/to/file_for_export

     Copy to Clipboard Toggle word wrap