Linux-3.14.12 Memory Management Note "Memory Leak detection Kmemleak example" "Go"

This article was reproduced from: http://blog.chinaunix.net/uid-26859697-id-5758037.html

After analyzing the Kmemleak implementation, test it as usual to determine the function is normal.

As with Kmemcheck, this feature needs to be enabled in case the kernel is turned on. The main configuration items are: Config_debug_kernel, Config_have_debug_kmemleak, Config_debug_kmemleak, and the config_debug_kmemleak_ of the number of configuration information record bars Early_log_size, usually the number of configurations can not be modified, but for self-initiated initialization of the module, it is necessary to adjust, in order to record more information, to avoid omission.

When you compile the configuration kernel for make menuconfig, the configuration path is as follows:

Kernel hacking

+-->kernel debugging (the item needs to be turned on)

+-->memory debugging

+-->kernel Memory Leak Detector (turn on the item)

Of course, these configuration items are dependent on other configuration items and can be found in the make Menuconfig backslash search for the corresponding configuration item.

There are a few things to be aware of in the setup process: The Kernel memory leak detector After opening a few of the children are careful not to set up, which is "simple test for the Kernel memory leak Detector "and" Default Kmemleak to Off ".

For example, the configuration options in the experiment are set as follows:

After compiling the kernel, install the debug version of the kernel, reboot the Linux system, and enter the new kernel. You will be able to see the existence of the path file to/sys/kernel/debug/kmemleak. If present, it indicates a successful start.

The experiment still uses 64-bit system to do the demonstration, modifies the experiment code in front Kmemcheck, constructs the memory leak. The specific code is as follows:

2. #include <linux/init.h>
4. #include <linux/module.h>
6. #include <linux/mm.h>
8. #include <linux/slab.h>
10. #include <asm/page.h>
14. void Kmemleak_memalloc (void)
16. {
18. Char *pmem;
22. Pmem = Kmalloc (Gfp_kernel);
24. if (!PMEM)
26. {
28. PRINTK ("[Kmemleak]: Kmalloc fail!\n");
30. }
32. Else
34. {
36. PRINTK ("[Kmemleak]: kmalloc return%p \ n", Pmem);
38. }
40. }
44. int __init kmemleak_test_init (void)
46. {
50. PRINTK ("[Kmemleak]: kmemleak_test_init! \ n ");
54. Kmemleak_memalloc ();
58. return 0;
60. }
64. void __exit kmemleak_test_exit (void)
66. {
68. PRINTK ("[Kmemleak]: Kmemleak_test_exit now \ n");
70. }
76. Module_init (Kmemleak_test_init)
78. Module_exit (Kmemleak_test_exit)
82. Module_license ("GPL");

Makefile script after a minor modification:

1. Obj-m = KMEMLEAK_TEST.O
3. All
4. Make-c/lib/modules/' uname-r '/build m= ' pwd '
6. Clean
7. Rm-f *.o *.ko *.mod.c modules.order module.symvers

After compiling the kernel Ko, through the ismod command installation module, according to the code to write the printed log information, through the DMESG to confirm the module initialization is complete and memory application is appropriate.

The relevant information is as follows:

In order to ensure the success of the experiment, KO installed after the wait a few minutes later.

Memory scan detection via command: Echo Scan >/sys/kernel/debug/kmemleak. The test results will be recorded in the/sys/kernel/debug/kmemleak file. By DMESG information, you can see that the requested memory space is located at the 0xffff95c9bf81b600 address. By searching, you can see the information record in Kmemleak:

Kmemleak the information of the test results, the information of the call stack requesting the memory, the memory header 32byte and the memory address and size of the leak are clearly recorded. But the size here is not a very precise size, here is the size of a slab memory piece, the size of the application in the experiment is 300 bytes, corresponding to 512 bytes of slab slices. The specific combination of code analysis part is omitted, that is the basic ability of the developer must, I do not swim.

Next, the control parameters of Kmemleak are described, and the control kmemleak mainly by writing parameters to the/sys/kernel/debug/kmemleak file. For example, the command that enables Kmemleak to scan for memory leaks is written to scan, with the specific command: Echo Scan >/sys/kernel/debug/kmemleak. The parameters used to clear the Kmemleak scan result are clear, and the corresponding commands are: Echo clear >/sys/kernel/debug/kmemleak.

More Kmemleak parameters are:

2. Off-disable Kmemleak (Irreversible)
4. Stack=on-enable the task stacks scanning (default)
6. Stack=off-disable The Tasks Stacks scanning
8. Scan=on-start the automatic memory scanning thread (default)
10. Scan=off-stop the automatic memory scanning thread
12. Scan=<secs>-Set the automatic memory scanning period in seconds
14. (default 0 to stop the automatic scanning)
16. Scan-trigger A memory scan
18. Clear-clear List of current memory leak suspects
20. Marking all reported unreferenced objects grey
22. dump=<addr>-Dump information about the object found at <addr>

If you are testing a kernel module, the correct procedure should be:

1. Clear Kmemleak historical information to record new data:

#echo Clear >/sys/kernel/debug/kmemleak

2. Load the kernel modules that need to be tested and execute relevant test cases;

#ismod ***.ko

3. Enable Kmemleak to scan for memory leaks:

#echo Scan >/sys/kernel/debug/kmemleak

4. View the results of the analysis scan:

#cat/sys/kernel/debug/kmemleak

At this point, the experiment is complete, kmemleak is very useful, suitable for kernel module development to detect the location of memory leaks.

Linux-3.14.12 Memory Management Note "Memory Leak detection Kmemleak example" "Go"