GDB debugging call executable

GDB debugging call executable file

Article directory

GDB debugging call executable
- Check whether coredump function is enabled
- Find core_pattern first
- coredump is automatically processed by the apport.service service program in the ubuntu system
- Analysis of common causes of coredump
- Use GDB and several commonly used GDB commands

The reason is that when running an executable file, a package error occurs:

 Not supported!

Segmentation fault (core dumped)

Because I couldn’t understand it, I hoped to figure out what problem caused this, so I started searching.
There are actually quite a few tutorials on this topic online. Here are some for you to pick up:

Use coredump to help solve segmentation fault problems
Method of generating core dump under Linux and parsing core dump file with gdb
Detailed explanation of coredump
In fact, the main thing is to find this coredump file first. I looked at it for a while, and finally got it out after going around and around.

Below is a record of my journey here.

Check whether the coredump function is enabled

If this function is not turned on, the file cannot be generated. Take one of my executable files as an example:
The directory where this executable file is located is:

 /home/be/workspace/BionicEyes/bin/

Then first you need to confirm whether the core dump function of the current session is turned on, 0 means it is turned off:

 cd /home/be/workspace/BionicEyes/bin/
// Then run the commands on the Internet
ulimit -c
0

This can be done until the core dump function of the current executable file is turned off.
Now run this command:

 ulimit -c unlimited

There is no limit on the size of the generated core dump file.
However, the scope of ulimit is the current shell process and its derived sub-processes. If the user runs two shell terminal processes at the same time and only sets ulimit -c unlimited in one of the environments, it will only be created in that process. The core dump file takes effect, and neither another shell terminal nor the child processes running on it will be affected.
To take effect in all shell windows, you need to modify the /etc/profile file:
Add in /etc/profile:

 ulimit -c unlimited
// After saving and closing
source /etc/profile

Effective in all shell windows.

Find core_pattern first

Finding this file is actually easy. The general path is under the /proc/sys/kernel/core_pattern path in the root directory.
Some tutorials on the Internet recommend writing it and saving the coredump file in another directory. I tried here. If I use the echo command, the command does not have enough permissions. Even if I use the sudo permissions, it is not enough, so I changed the method.
This method also modifies the saving directory of the coredump file, but only modifies the file in the /etc/sysctl.conf path.
Still refer to this blog: Changing the coredump file generation path under Linux
The temporary method is to get one as mentioned above, but the permissions are not enough, so the permanent method is adopted.
Add the following line to the /etc/sysctl.conf file:

 kernel.core_pattern = /var/crash/%t-%e-%p-%c.core //This is my own path and you can change it yourself.

The meaning of the characters can be found in the blog above.
Then run:

 sudo sysctl -p

In this way, the path of the coredump file can be permanently modified. When the running program crashes, the corresponding coredump file will be generated in the /var/crash directory, for example:

Which! means /, so this file is actually the coredump of the executable file under the path /home/be/workspace/BionicEyes/bin/ Documents.

coredump is automatically processed by the apport.service service program in the ubuntu system

What is the reason for this?
ubuntu By default, a service program apport.service is enabled in the system. That is to say, a crash report is automatically generated, in order to automatically collect errors.
When viewing the core_patten file, the results are as follows:

 cat /proc/sys/kernel/core_pattern
    |/usr/share/apport/apport %p %s %c %d %P

Indicates that apport handles coredump files;

Solution: You can close the system’s apport.service service program (Note: This method is only a temporary shutdown. After the system is restarted, the apport.service service program will turn on again).

Enter the following command to temporarily shut down the service:

 sudo service apport stop //Close error reporting

Permanently close apport, modify /etc/default/apport, set enabled =0
Afterwards, restart Ubuntu and apport will no longer start.

Analysis of common causes of coredump

Memory access out of bounds
Using wrong subscripts leads to out-of-bounds array access;
Multithreaded program uses thread-unsafe functions
Data read and written by multi-threads is not protected by locks;
illegal pointer
a) Use a null pointer,
b) Feel free to use pointer conversions;
stack overflow
Do not use large local variables (because local variables are allocated on the stack), which can easily cause stack overflow, damage the system’s stack and heap structure, and cause inexplicable errors.

Use GDB and several commonly used GDB commands

Enter the terminal in the folder where the executable file is located and enter gdb to enter the corresponding debugging environment:

Then enter the corresponding command after (gdb) to debug.

l(list): Display the source code and you can see the corresponding line number;
b(break) N: N is the line number, which means setting a breakpoint at the corresponding line number;
p(print) X: X is the variable name, which means printing the value of variable X;
r(run): Continue execution to the breakpoint location
n(next): Single step to the next step
c(continue): Continue execution;
q(quit): Exit gdb;
backtrace: View the function call stack information before the error;
info threads: View the instruction information of all threads running;
thread apply all bt: Open the stack information of all threads;
thread apply threadID bt: View the stack information of the specified thread (threadID is the number of the stack);

For example: