Gdb debugging positioning accuracy and in?? problems

This article mainly discusses the accuracy with which gdb can locate the problem when using gdb to track down program errors, and the factors that affect gdb debugging.

1. Check whether a dynamic library (.so file) or executable file is a debug version.

readelf -S libxxx.so |grep debug

If there is output, it means the debug version

2. Whether g++ is compiled with -g or not will affect later debugging

The following test code, the source code is testso.cpp, and a dynamic library libmyso.so is linked, and the dynamic library libmyso.so is compiled from so.cpp. Among them, so.cpp has an out-of-bounds error, and a segmentfault error is reported after running.

| testso.cpp testso.h
| so.cpp so.h

testso.cpp content

 #include <iostream>
 #include <vector>
 #include "./so.h"
 using namespace std;
 int main()
 {
    
    
       testso();
 }

• Generate a dynamic library and compile testso.cp without adding the -g parameter

g++ so.cpp -fPIC -shared -o libmyso.so
g++ testso.cpp -l myso -o a.out

After the compilation is successful, run a.out. The program is down to generate the core file.

gdb ./a.out corefile

As shown in the figure, you can see the call stack, but you can't determine which line

• Generate dynamic library without adding -g , compile testso.cp with -g parameter

g++ so.cpp -fPIC -shared -o libmyso.so
g++ -g testso.cpp -l myso -o a.out

An error occurred in the seventh line that can locate testso.cpp

• Generate dynamic library with -g parameter, compile testso.cp without -g parameter

g++ so.cpp -fPIC -shared -o libmyso.so
g++ -g testso.cpp -l myso -o a.out

so.app can locate the line, but testso.cpp cannot. From the above, it can be briefly summarized: only if the -g parameter
is added , gdb debugging can be accurate to the line, whether it is a dynamic library or its own source code.

3.gdb debugging shows that the stack information is in??()

gdb is not a panacea. In many cases, it may appear that the stack information after executing bt is all in??. The possible reasons so far known are:

• The stack information is destroyed when the program exits abnormally
• The running environment is inconsistent with the debugging environment
  . In the former case, it will be more difficult to use gdb for further positioning. You can consider using other tools to locate the problem, such as valgrind. When I encountered this problem, I used valgrind's memory analysis to finally find the crash of the abnormal program.