The so -called GDB is a common debugging tool in Linux. It is still very beneficial when writing some simple projects, but if the project is large, it is designed to be designed to be in many processes. Use the Printf function to detect the problem. Using GDB debugging, you need to add -g when compiling GCC. For example, GCC File.c -G -O App. Below is some commonly used shortcut keys of GDB, for your reference only.
(The following brackets represent the abbreviation, if there is no follow -up key behind the shortcut key, it means that there is no short abbreviation for this shortcut key)
help (h), list the command line according to the module.
List (L), display code, check the current code.
Start, start running.
RUN (R), run at full speed.
next (n), the next step, this next step refers to the next step in the process, which is equivalent to the F10 shortcut key in VS. When debugging, one function is used as one step.
Step (s), the next step, the next step is the next step. It is equivalent to the F11 shortcut key in VS. When debugging, enter the function to debug one by step, but you can only jump into the function written by your own. You cannot jump into the C standard library function, such as the FOPEN function, and so on.
Print (P), print
BREAK (B)+line number/function name, set a breakpoint in the line number assigned in GDB, this line number is not the line number corresponding to the function you wrote.
info (i), check the value of the internal variable of GDB.
Info Breakpoints, display breakpoints.
ENABLE BREAKPOINTS, enable the breakpoint.
Disable Breakpoints, disabled breakpoints, generally exit directly, so rarely use it.
Continue (C), continue, stop before the breakpoint.
Breaktrace (BT), the stack and hierarchical relationship of the function call, (the most obvious observation in the callback function).
Frame (f)+stack 桢 (this stack is obtained through Breaktrace), switch the stack of the function. Although the stacks are switched at this time, if the next step is executed at this time, it is still the next step of the original stack, not the next step after switching.
set var n = 100. Set the value of the variable.
ctrl+p, turn over the command.
Quit, end GDB.
Finish, end the current function and return to the call point of the function.
Display, set the observation variable, and then each time the next step will be displayed, the value of the variable set is displayed.
WATCH, when the variables on the observation point are modified, the printing display.
info (i) watch, displaying the observation point.
undisplay+number, cancel the observation variable.
x, view the memory.
Core file, you can see where the program is executed before the program is broken, and then find out the reason for the error. But the default core file size in Ubuntu is 0, so you can’t write things inside. If you want to open it, you only need to use it
Ulimit -C 1024 (setting the size of the file) can be turned on with the core file. Use GDB App Core when debugging.
In Fork (), when there is both a parent process and a child process, use set follow_Fork_mode Child to track the process, and use the set follow_Fork_mode paint to track the parent process, but this is not very useful in the multi -process. If the program is If there is a dead cycle, it may cause it to end. At this time, you can only use Kill to kill the process number to solve it.