Shulou(Shulou.com)06/01 Report--

This article mainly introduces "how to create and debug dump files on Linux". In daily operation, I believe many people have doubts about how to create and debug dump files on Linux. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to create and debug dump files on Linux". Next, please follow the editor to study!

Crash dump, memory dump, core dump, system dump. All of this produces the same product: a file that contains the memory state of the application at that particular moment when the application crashes.

This is a guide, and you can follow through by cloning the application repository of the examples:

Git clone https://github.com/hANSIc99/core_dump_example.git

How the signal correlates to the dump

The signal is the interprocess communication between the operating system and the user application. Linux uses signals defined in the POSIX standard. On your system, you can find the definition of the standard signal at / usr/include/bits/signum-generic.h. If you want to know more about using signals in your application, there is an information-rich signal man page. Simply put, Linux triggers further activity based on expected or unexpected signals.

When you exit a running application, the application usually receives a SIGTERM signal. Because this type of exit signal is expected, this operation does not create a memory dump.

The following signal will result in the creation of a dump file (source: GNU C library):

SIGFPE: wrong arithmetic operation

SIGILL: illegal instruction

SIGSEGV: invalid access to storage

SIGBUS: bus error

SIGABRT: errors detected by the program and reported by calling abort ()

SIGIOT: this signal is out of date on Fedora. In the past, it was triggered when abort () was used on PDP-11, but now it maps to SIGABRT.

Create a dump file

Navigate to the core_dump_example directory, run make, and execute the sample binary using the-C1 switch:

. / coredump-C1

The application will exit in status 4 with the following error:

Dump written "Abgebrochen (Speicherabzug geschrieben)" (LCTT translation note: this is German, should be because the author's system is German environment) is roughly translated as "segmented failure (core dump)".

Whether to create a core dump is determined by the resource constraints of the user running the process. You can modify the resource limit with the ulimit command.

Check the current settings for creating core dumps:

Ulimit-c

If it outputs unlimited, it uses the (recommended) default value. Otherwise, correct the limitation in the following ways:

Ulimit-c unlimited

To disable the creation of a core dump, you can set its size to 0:

Ulimit-c 0

This number specifies the size of the core dump file in blocks.

What is a core dump?

The way the kernel handles core dumps is defined as:

/ proc/sys/kernel/core_pattern

I am running Fedora 31, and on my system, the file contains:

/ usr/lib/systemd/systemd-coredump% P% u% g% s% t% c h

This indicates that the core dump is forwarded to the systemd-coredump tool. In different Linux distributions, the content of core_pattern can vary greatly. When using systemd-coredump, the dump file is compressed and saved under / var/lib/systemd/coredump. You don't need to have direct access to these files, you can use coredumpctl. For example:

Coredumpctl list

All available dump files saved in the system are displayed.

Using coredumpctl dump, you can retrieve information from the last saved dump file:

[stephan@localhost core_dump_example] $. / coredump Application started... (. (.) Message: Process 4598 (coredump) of user 1000 dumped core. Stack trace of thread 4598: # 0 0x00007f4bbaf22625 _ GI_raise (libc.so.6) # 1 0x00007f4bbaf0b8d9 _ GI_abort (libc.so.6) # 2 0x00007f4bbaf664af _ libc_message (libc.so.6) # 3 0x00007f4bbaf6da9c malloc_printerr (libc.so.6) # 4 0x00007f4bbaf6f49c _ int_free (libc.so.6) # 5 0x000000000040120e ngamma a (/ home/stephan/Dokumente/core_dump_example/coredump) # 6 0x00000000004013b1 ngamma a (/ home/stephan/Dokumente) / core_dump_example/coredump) # 7 0x00007f4bbaf0d1a3 _ libc_start_main (libc.so.6) # 8 0x000000000040113e nouch a (/ home/stephan/Dokumente/core_dump_example/coredump) Refusing to dump core to tty (use shell redirection or specify  -  output).

This indicates that the process was stopped by SIGABRT. The stack trace in this view is not very detailed because it does not include function names. However, with coredumpctl debug, you can simply open the dump file with the debugger (default is GDB). Enter bt (short for backtracking backtrace) for a more detailed view:

Core was generated by `. / coredump-C1. Program terminated with signal SIGABRT, Aborted. # 0 _ GI_raise (sigsig=sig@entry=6) at.. / sysdeps/unix/sysv/linux/raise.c:50 50 return ret (gdb) bt # 0 _ GI_raise (sigsig=sig@entry=6) at.. / sysdeps/unix/sysv/linux/raise.c:50 # 1 0x00007fc37a9aa8d9 in _ _ GI_abort () at abort.c:79 # 2 0x00007fc37aa054af in _ libc_message (actionaction=action@entry=do_abort, fmtfmt=fmt@entry=0x7fc37ab14f4b "% s\ n") at. / sysdeps/posix/libc_fatal.c:181 # 3 0x00007fc37aa0ca9c in malloc_printerr (strstr=str@entry=0x7fc37ab130e0 "free (): invalid pointer") at malloc.c:5339 # 4 0x00007fc37aa0e49c in _ int_free (av=, p = Have_lock=0) at malloc.c:4173 # 5 0x000000000040120e in freeSomething (void*) () # 6 0x0000000000401401 in main ()

The memory addresses of main () and freeSomething () are quite low compared to subsequent frames. Because the shared object is mapped to the area at the end of the virtual address space, the SIGABRT can be considered to be caused by calls in the shared library. The memory address of a shared object is not constant between multiple calls, so when you see that the address is different between multiple calls, it can be considered a shared object.

The stack trace shows that subsequent calls originate from malloc.c, indicating that there may be something wrong with the (de) allocation of memory.

In the source code (even without any knowledge of C++) you can see that it attempts to release a pointer that is not returned by the memory management function. This leads to undefined behavior and leads to SIGABRT.

Void freeSomething (void * ptr) {free (ptr);} int nTmp = 5; int * ptrNull = & nTmp; freeSomething (ptrNull)

The coredump tool for systemd can be configured in / etc/systemd/coredump.conf. Rotational cleanup dump files can be configured in / etc/systemd/systemd-tmpfiles-clean.timer.

You can find more information about coredumpctl in its man page.

Compile with debug symbols

Open Makefile and comment out the last part of line 9. Now it should be like this:

CFLAGS =-Wall-Werror-std=c++11-g

The-g switch enables the compiler to create debugging information. Start the application, this time using the-c2 switch.

. / coredump-c2

You'll get a floating-point exception. Open the dump file in GDB:

Coredumpctl debug

This time, you will be directed directly to the line in the source code that caused the error:

Reading symbols from / home/stephan/Dokumente/core_dump_example/coredump... [New LWP 6218] Core was generated by `. / coredump-c2percent. Program terminated with signal SIGFPE, Arithmetic exception. # 0 0x0000000000401233 in zeroDivide () at main.cpp:29 29 nRes = 5 / nDivider; (gdb)

Type list for a better overview of the source code:

(gdb) list 24 int zeroDivide () {25 int nDivider = 5; 26 int nRes = 0; 27 while (nDivider > 0) {28 nDivider--; 29 nRes = 5 / nDivider; 30} 31 return nRes; 32}

Use the command info locals to retrieve the value of the local variable from the point in time when the application failed:

(gdb) info locals nDivider = 0 nRes = 5

Combined with the source code, you can see that you encounter a zero division error:

NRes = 5 / 0

Conclusion

Knowing how to handle dump files will help you find and fix random errors in your application that are difficult to reproduce. If it is not your application, forwarding the core dump to the developer will help her or him find and fix the problem.

At this point, the study on "how to create and debug dump files on Linux" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.