Original address: https://blog.csdn.net/hexieshangwang/article/details/47187877
1.
Overview The main reason for handle leakage is that the process does not release the opened file handle after calling the system file.
For handle leakage, it can affect the normal operation of a functional module, or cause the entire application to crash. In Windows system, the upper limit of GDI handle is 12000, and the upper limit of USER handle is 18000.
Different from the Windows system settings, the Linux system limits the number of file handles that a process can call. By default, the maximum number of handles that each process can call is 1024. Beyond this value, the process cannot obtain a new handle. Therefore, the leak of the handle will cause great hidden danger to the function failure of the process.
In theory, when we are programming, it is recommended that the number of handles used by one process should not exceed 1000.
2. Analysis
According to the testing experience of our project, there are usually three types of handle graphs:
1. Stationary type
Figure 2-1. Stationary graph
During the running of the program, the handle is opened and closed continuously, so the statistical graph presents a smooth zigzag shape. In the later stage of the program running, many temporarily opened handles are gradually closed, and the total number of handles does not increase over time, so the program does not have handle leaks.
2. Peak Stable
Figure 2-2. Peak Stable Graph
At the beginning of the program running, the number of handles opened by the program will gradually increase over time. But after running for a
period of time, the number of handles will reach a relatively stable state, about 3500. At this time, it indicates that the program has opened
a lot of temporary handles, but the number of handles is relatively stable, and there is no handle leakage problem.
3. Incremental type
Figure 2-3. Incremental graph
During the running of the program, a certain operation causes the number of open handles of the program to gradually increase, and there is no sign of relative stability, indicating that the program may have handle leaks, and it is necessary to further analyze which part is it There is a leak of the handle of the program, and what operation will cause the leak of the program handle.
By sampling statistics on the number of program handles and drawing corresponding statistical graphs, it is possible to judge whether there is a handle leak in the program in a more intuitive way. This method is based on the program to run a large number of test cases, increase the coverage of test cases, and use as many test cases as possible to trigger the operation of the program to open and close handles, so as to discover potential handle leak bugs. We will do further research on how to quickly find handle leaking code.
3. Positioning (WinDBG debugging)
1. Run the program
WinDbg provides two operation modes: graphical interface and command line. Here is an introduction to use the graphical interface of WinDbg to
debug application:
File->OpenExecutable->You can select an executable file for debugging.
File->Attache to a Process->You can select a running process and debug it.
Figure 3-1
2. The stack traceback for starting the handle operation
Press F5 shortcut key to interrupt the process running for the first time, and use the !htrace -enable command to enable the handle detection; htrace
provides the command to perform the handle-related detection, you can view the WinDBG help documentation.
Figure 3-2
Run the program with the g command at the same time.
Figure 3-3
3. Take a snapshot
The second time the process is interrupted, use! htrace -snapshot command to get a mirror image of the process handle at this time. and let the program run again.
Figure 3-4
the third time, use it! The htrace -diff command obtains the difference between the current handle state and the snapshot mirror handle in step 3;
Figure 3-5
shows the open place of the handle through the stack traceback information above. Use the lsa command to locate the method body code line that produces
the handle leak, lsa handlew2!fun4+0x0000002e:
