The importance of GDB is stated in the previous speech
In general, the mention of GDB is a command to debug. "Command", which is almost equivalent to a complex term for the user. Although this is true, the actual development debugging must be used by GDB. Today, most Linux systems are present in the server. When we want to operate these systems, we generally operate through terminal. This means that these Linux systems do not have a graphical interface. Debugging is generally divided into two parts, development debugging and runtime debugging. When our program is deployed on Linux, it's time to forget about the damn graphics debugger.
To talk about the purpose of writing this article
Yesterday the company's game, which served the end of the crash. I forgot the GDB command-_-! when I was debugging (I finally found out the bug, of course). So write this blog post to deepen your memory and share your experience.
Basic commands
Note: GDB is far more than this few commands
1. Attach: Debugging a running process with GDB
GDB <program> pid or GDB attach PID
2. BR: Set Breakpoints
BR Filename:line_num
BR Namespace::classname::func_name
3. N: Single Step skip S: Step Into
4. Finish: Execute to function Retun return
5. List: list 10 lines of code after the current position; list Line_number: list 10 lines of code after Line_number
6. BT (backtrace): List the call stack (same type and where, experience tells me that when you want to list the stack information, and found no effect, it is best to try two commands)
7. Info locals: List The local variables of the current function
8. P VAR_: Print variable values
9. Info breakpoints: List all breakpoints
Delete breakpoints: Remove all breakpoints; Delete Breakpoints ID: remove breakpoint with ID; disable/enable Breakpoints ID: Disable/Enable breakpoint
Break ... if ... Conditional interrupts
I'm mainly talking about run-time debugging.
Test code
#include <stdio.h>void Crash () { int *a; *a = 1; printf ("%d\n", *a);} void Endlessloop () { int i = 1; int j = 0; while (i) { ++j; }} int main () { Crash ();//Crash Endlessloop ();//Dead Loop return 0;}
Debugging crashes
Http://blog.csdn.net/yitouhan/article/details/17175113 This is an article I wrote earlier about preventing crashes.
The core file is used here:
When a program crashes, it typically generates a core file in the specified directory. The core file is simply a memory image (plus debugging information), which is used primarily for debugging purposes.
The core file name is typically the core. PID, i.e. core.3745, etc.
I typically set up Linux support for Core in/etc/security/limits.conf (Centos), which requires rebooting the system and then permanently supports printing the core file.
Add the following command
* Soft Core Unlimited
* Hard Core Unlimited
This means that both the software and the hardware print the core file and are unlimited (unrestricted). Here you can replace the unlimited with the specified size.
Note: There are other ways to set up, you can search the Internet on your own query.
At this point, the service side test crashed. I found core.1234 this file in my working directory (the core file is exported to the working directory by default).
Enter GDB test core.1234 to enter GDB debugging.
Then enter where to view the stack information, such as:
See this information, don't tell me there is no place to go wrong?!
Debug a dead Loop
Do not abort the process when we find a dead loop. Assuming the process ID is 1234
Input command GDB attach 1234
You will find that GDB will break breakpoints in the dead loop where it may not be clear that you can always enter N. Note the line number, and you'll see that this is where the dead loop occurs.
Then enter where to view the stack information, as shown in.
See this information, don't tell me there is no place to go wrong?!
Half-dead cycle
Half-life cycle (this is my own use of a noun, do not know whether other tutorials are used) is in the run time error, resulting in a loop millions of times, tens of millions of times or even hundreds of millions of times a bug.
Although this bug is relatively less harmful than crashes and dead loops, it is much harder to debug. If you have a better debugging experience with this bug, I hope you can share it!
Debugging the game server with GDB