GDB debugging

1.gdb What is it? ？

website ：

  GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

  GDB yes GNU Project debugger , It allows you to see how the program is executed internally , Or what the program is doing when it crashes . To put it bluntly, it is a tool for debugging programs .

  GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

  GDB There are four types of things you can do to help you capture the real bug.

• Start your program, specifying anything that might affect its behavior.

   Start the program , View any details that affect the behavior of the program .
  

• Make your program stop on specified conditions.

   Let your program stop under certain conditions .
  

• Examine what has happened, when your program has stopped.

   Test what happens when your program stops .
  

• Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

2.demo

 The following are the procedures with problems test_error.c have undue discussion over sth. .

#include<stdio.h>

int main()
{    
    int* pNum = NULL;
    *pNum = 100;
    return 0;
}

   First compile the program and then enter the debug state ：

• among -g Is to generate a symbol file , Otherwise, when using gdb When debugging, you will be prompted that there is no symbol file , As shown in the figure below .

 

 

3.gdb Command and debugging

First apt-get install gdb Installation .

• gdb a.out ： Enter debugging state .

• list ： List program code , Contains the number of rows Then you can set the breakpoint .

• break（r）： To set breakpoints ：b 3 perhaps b main On the third line or main Set breakpoint at function .

• run（r）： Program execution .

• print（p） Variable ： View the information of the variable at the current breakpoint .

• info b ： View breakpoint information .

• next（n）： Step by step .

  Here is a simple debugging process ：

 

4. Debug crash core file

     When we run programs, we often encounter ： Segment error , The core has been dumped . Or just a segment error , Note that in this case it is because ulimit The problem of , So no crash information file is generated .

When we need to debug a crash program , First you have to generate a crash information file ：core.

• ulimit -c View the allowed crash file size , If it is not turned on, the result is 0.
• ulimite -c unlimited It can be opened manually .

Next launch gdb Run the following command ：

gdb a.out core

gdb Will go directly to your crash code ！ Here's the picture ：

  Then it will jump directly to the crash code . This is because p A null pointer is assigned a value ！

 5. debugging nodejs

Pay attention to gdb Method for setting parameters in ：set args a b c

When nodejs Called C++ plug-in unit , When there is a crash in the plug-in , It can also be used. gdb To debug .

  Directly in js You may not see a direct problem when calling ：

At this point gdb debugging ： 

  At this point, the problem is directly located in . At first gdb You can't give it when you go in .node Set breakpoint's （ Or I won't ）,r Then it will be loaded , After input list It will show demo.cc Code for , At this point b、n Set breakpoints and single step debugging .

in addition ： It seems that you can break the library file directly ： In this case, you actually need the source file  

 

6. Call it a day

perfect！