Summary of several methods for locating program problems through valgrind and GDB

Location through valgrind and GDBProgramSummary of several methods

 

1. Use valgrind to locate program Problems

We often use GDB when troubleshooting program problems. GDB is indeed a useful tool for locating program problems. However, we often use GDB to locate the problem and find that it is difficult to locate it. It takes a lot of time to locate the location where the core occurs, however, I still don't know why this error occurs-because the errors before core often occur.

At this time, don't forget another tool, valgrind. Based on my experience in locating program problems, valgrind often surprises me. Therefore, I think it is necessary to pay attention to this tool because it does bring us a lot of convenience.

I will not specifically describe the principles and usage of valgrind here. There are a lot of related documents on the Internet. If you are interested, you can find relevant information on the Internet. Here I will introduce the situation of our QQ Show:

1: Use valgrind to locate CGI and FastCGI:

1) Use valgrind to locate CGI problems:

There are two prerequisites:

A) CGI must be an executable program, which means that when locating FastCGI (dynamic library), it needs to be compiled into CGI (Executable File) form;

B) when running CGI, You need to configure the environment variable (CGI obtains the client request through the environment variable to read the request packet information). In qzthhp, for the CGI Environment Variable, it is set by qzhhtp. Now we need to configure the environment variable ourselves when we need to run CGI separately:

Setting method:

First, we get the request package through httpwatch:

Configure environment variables according to the request package:

Export request_method = post

Export QUERY_STRING = "parm1 = 1 & parm2 = 2 &... "

Exporthttp_cookie = "vid = 1011255824; FLV = 9.0; pt2gguin = o0249694429; airkey = c14101efd87eb ...... "

Export content_type = ""

Export content_length = ""

Compile CGI into an executable file and run: (for example, qqshow_user_info)

Valgrind -- log-file-exactly = Allen. log -- tool = memcheck -- leak-check = yes./qqshow_user_info

PS: If it is post mode, it will wait for the input after run and copy the parameter directly to the input. For example, "parm1 = 1 & parm2 = 2 &...", Press Ctrl + D or enter to complete the input, and the program continues to run

Analyze Allen. log to locate program problems.

2) use the encapsulated valgrind tool leakscan to locate CGI and FastCGI

Every day, you will receive an email "CGI Memory Leak Scan (qqshow)", which probably reports the memory usage of CGI/fasctgi, although the title is "memory leak ", but it does not only report Memory leakage. In fact, valgrind is used for the detection tool, which is encapsulated. It is also the leakscan tool developed by O & M personnel.

As mentioned above, it is difficult to manually configure and run CGI: 1) FastCGI must be re-compiled into CGI; 2) a lot of environment variables should be configured;

This is not required for leakscan. This tool has been installed in the Development qqshow development environment. The running file is:

/Usr/local/services/leakscan

Before running the program, you need to save the httpwatch request package as a file, for example

Qqshow_user_info.txt, Which is uploaded to the development machine through CRT, for example, under/home/user_00/, then

CD/usr/local/services/leakscan/

./Leakscan/usr/local/qqshow/cgi-bin/qqshow_user_info/home/user_00/qqshow_user_info.txt

2: Use valgrind to locate server problems:

The server of qqshow is generally built using the servrbeach ++ (s ++ for short) platform component. We compile the corresponding plug-ins according to the business.

By modifying the S ++ configuration file, we can embed valgrind to analyze server problems;

Take the QQ mail Transit server as an example:

Qqmail Development Environment (172.23.2.199) Server Directory:/usr/local/services/qqmailserver/

Configuration File:/usr/local/services/qqmailserver/etc/

Qqmail_ctrl.xml

Qqmail_proxy.xml

Qqmail_worker.xml

If we want to locate the businessCodeYou can solve the problem by modifying qqmail_ctrl.xml ,:

 

Modification point:

1) Add valgrind:

EXE = "./_ valgrind -- log-file = Allen. log -- tool = memcheck -- leak-check = yes./qqmail_worker"

PS: Because the basepath on the configuration file is the bin directory, if valgrind is used directly, it will prompt that the command cannot be found. I will simply create a symbolic link below the bin:

 

 

2) modify the number of workers:

Because we only need to locate the problem and set the number of workers to 1, so that we can locate the problem easily by modifying it to maxprocnum = "2" minprocnum = "1.

3) Start the server and you will be able to locate program problems by analyzing log-file.

 

PS:

1) Running valgrind will affect server performance and output valgrind to analyze logs, so it is best not to do so on the Internet;

2) When valgrind is embedded by modifying qqshow_ctrl.xml, The valgrind cannot be stopped when the server is stopped. In this case, you need to manually kill it.

3) After the analysis is complete, remember to restore the configuration file.

 

2. Analysis of CGI core files on the Internet: Analysis of core files that cause stack corruption due to a segment Error

CGI on the internet is generally not compiled in debug mode, and the core is often caused by segment errors. At this time, we use GDB for analysis. Although there are core files, it seems that we cannot provide the information, because GDB analysis does not know where the core occurs. Many people compile a debug version and locate it by printing logs. This method is relatively negative. Even if the core file of the stack is destroyed, it is very likely that the core file is located in some ways. The following describes the analysis method:

PS: This method was contributed by a student from KM.ArticleSummary: (Robert tyu posted on)

If debugging information is available, GDB program core is easy to locate unless the stack is written in disorder.

However, currently, our CGI has no debugging information (optimized during compilation or strip), or sometimes the stack is written down, the above GDB program core is not easy to define specific locations.

The following describes how to define an exception point address:

 

1. Find the core address in GDB;

 

 

2. Run the same batch of alive/proc/Pid/maps (the address is a little random each time after linux2.6, so it must be the same batch unless this feature is disabled ), or find the loading address of the CGI so in info file. If it is not a CGI. So issue, you can also see it here.

 

Note: the first is the executable segment, and the attribute is r-XP. The second RW is the data segment. If an exception occurs in another segment, you can check the segment in which the exception address is located to determine the module.

 

3. An abnormal offset is obtained after 1-2 of the preceding steps;

0xb79c844f-0xb7985000 = 0x4344f

 

4. objdump-d cgi-So> CGI. s disassembly.

 

5. Use the offset of 3 (hexadecimal) to locate the exception location.

 

As shown above, the problem lies in the cframettcclient: Get function. At the last layer of GDB prog core, you can use the info Reg command to view the ESI = 0 at that time, which is the direct cause of the core. The root cause of this bug is traced back to the previous layer.

6. The function is very small and it is easy to locate the problem. If it is large, read the ASM level. Therefore, we recommend that you write more small functions.

The above functions are relatively small, so the problem was quickly located. If the function is large, you can find the specific C/C ++ error location from the code with more features in ASM. Constants, strings, typical C/C ++ code compiled into ASM, and other constants involved in functions, comparisons, and assignments.

7. Generally, the core location is not the source of the Error. However, finding the wrong location and its features helps to locate the root cause of the problem.

In addition, because the Optimized Code (including strip) has no symbolic information, especially information about local variables, at this time, you can identify the address of the local variable through Reg and ASM at that time to check the content of the variable. These contents are sometimes very useful.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/macky0668/archive/2009/07/07/4328959.aspx