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

This article mainly introduces how to get a wrong core dump on Linux, which has a certain reference value. Interested friends can refer to it. I hope you can learn a lot after reading this article.

What is a mistake?

A "segment error segmentation fault" is a situation in which your program attempts to access a memory address that is not allowed to access. This may be due to:

Attempt to dereference null pointer (you are not allowed to access memory address 0)

Try to dereference other pointers that are not in your memory. (LCTT)

One that has been destroyed and points to the wrong place.

C++ virtual table pointer C++ vtable pointer

Which causes the program to attempt to execute instructions in memory that do not have permission to execute

There are other things I don't understand, such as I think accessing misaligned memory addresses can also lead to segment errors. (LCTT translation notes: in architectures that require natural boundary alignment, such as MIPS and ARM, segment errors are more likely to occur due to misaligned access.

This "C++ virtual table pointer" is a section of error in my program. I may explain this in my future blog, because I don't know anything about C++ at first, and I don't know how this virtual table lookup leads to program segment errors.

But! The post of this blog is not about C++. Let's talk about the basics, such as, how do we get a core dump?

Step 1: run valgrind

I find that the easiest way to find out why there is a segment error in my program is to use valgrind: I run

Valgrind-v your-program

This gives me a stack call sequence in the event of a failure. Simple!

But I also hope to do a more in-depth investigation and find out some information that valgrind didn't tell me! So I want to get a core dump and explore it.

How to get a core dump

The core dump core dump is a copy of your program's memory and is useful when you are trying to debug what went wrong with your problematic program.

When your program has a segment error, Linux's kernel sometimes writes a core dump to disk. When I first tried to get a core dump, I was very depressed for a long time because-Linux did not generate a core dump! Where is my core dump?

That's what I ended up doing:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Run ulimit-c unlimited before starting my program

Run sudo sysctl-w kernel.core_pattern=/tmp/core-%e.%p.%h.%t

Ulimit: set * size of core dump

Ulimit-c sets the * * size of the core dump. It is often set to 0, which means that the kernel does not write core dumps at all. It is measured in kilobytes. Ulimit is set on a per-process basis-you can see the various resource limits for a process by running cat / proc/PID/limit.

For example, these are the resource limitations of any Firefox process on my system:

$cat / proc/6309/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608 Unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 30571 30571 processes Max open files 1024 1048576 files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals 30571 30571 signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us

The kernel uses the soft limit soft limit when deciding which core dump file to write to (in this case, max core file size = 0). You can use the shell built-in command ulimit (ulimit-c unlimited) to increase the soft limit to the hard limit hard limit.

Kernel.core_pattern: where is the core dump stored?

Kernel.core_pattern is a kernel parameter, or "sysctl setting," that controls where the Linux kernel writes core dump files to disk.

Kernel parameters are a way to set the global settings of your system. You can get a list of each kernel parameter by running sysctl-a, or use sysctl kernel.core_pattern to specifically view the kernel.core_pattern settings.

So sysctl-w kernel.core_pattern=/tmp/core-%e.%p.%h.%t saves the core dump to the directory / tmp with a suffix of core plus a series of parameters that can identify the failed process as the file name.

If you want to know what these parameters such as% e and% p represent, please refer to man core.

It is important that kernel.core_pattern is a global setting-be careful when modifying it, as it is possible that other system functions depend on setting it to a specific way.

Kernel.core_pattern and Ubuntu

By default on ubuntu systems, kernel.core_pattern is set to the following values:

$sysctl kernel.core_patternkernel.core_pattern = | / usr/share/apport/apport% p% s% c% d% P

This caused me to wonder (what does this apport do and what does it do to my core dump? ). Here's what I've learned about this:

Ubuntu uses a system called apport to report crash information about apt packages.

Setting kernel.core_pattern= | / usr/share/apport/apport% p% s% c% d% P means that the core dump will be piped to the apport program.

The log of apport is saved in the file / var/log/apport.log.

By default, apport ignores crash information from binaries that are not part of the Ubuntu package

In the end, I just skipped apport and reset kernel.core_pattern to sysctl-w kernel.core_pattern=/tmp/core-%e.%p.%h.%t, because I'm on a development machine, I don't care if apport works, and I don't want to try to get apport to keep my core dump on disk.

Now that you have a core dump, what's next?

Okay, now we know about ulimit and kernel.core_pattern, and we actually have a core dump file in the / tmp directory of the disk. Great! What's next? We still don't know why there is an error in the program!

The next step is to use gdb to open the core dump file and get the stack call sequence.

Get stack call sequence from gdb

You can open a core dump file with gdb like this:

$gdb-c my_core_file

Next, we want to know what the stack looks like when the program crashes. Running bt at the gdb prompt will give you a call sequence backtrace. In my example, gdb does not load symbolic information for binaries, so these function names look like "?". Fortunately, we fixed it (by loading symbols).

Here is how to load debug symbols.

Symbol-file / path/to/my/binarysharedlibrary

This loads symbols from the binary and any shared libraries referenced by it. Once I do this, when I execute bt, gdb gives me a nice stack trace with a line number!

If you want it to work, the binaries should be compiled with debug symbol information. The line number in the stack trace is very helpful when trying to find out why the program crashed. :)

View the stack of each thread

Get the call stack for each thread in gdb in the following ways!

Thread apply all bt fullgdb + core dump = surprise

If you have a core dump with debug symbols and gdb, that's great! You can LCTT up and down the call stack, print variables, and look at memory to see what's going on. This is *.

If you are still working based on the gdb wizard, you can just print out the stack trace and bt. :)

ASAN

Another way to figure out your segment errors is to compile the program ("ASAN", that is, $CC-fsanitize=address) with the AddressSanitizer option and run it. I'm not going to discuss that in this article, because this article is quite long, and the error in opening ASAN disappeared in my example, probably because ASAN uses a different memory allocator (system memory allocator, not tcmalloc).

If I can make ASAN work in the future, I may write more about it. (LCTT translation note: this means that using ASAN can also reproduce segment errors.)

It's really nice to get a stack trace from a core dump!

It sounds like a lot, and I'm confused when I do this, but to be honest, it doesn't take that many steps to get a stack call sequence from a segment of the wrong program:

Try valgrind

If that doesn't work, or you want to get a core dump to investigate:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Make sure the binary file is compiled with debug symbol information

Set up ulimit and kernel.core_pattern correctly

Run the program

Once you have debugged the core dump with gdb, load symbols and run bt

Try to find out what happened!

Thank you for reading this article carefully. I hope the article "how to get a wrong Core dump on Linux" shared by the editor will be helpful to everyone. At the same time, I also hope you will support us and follow the industry information channel. More related knowledge is waiting for you to learn!

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.