Re: Exact leak location in KMemleak Output
Sankar and All, I followed blow investigation on detecting kernel memory leak. I got different o/p which is different from yours shown. ie, 4 and 5 lines are addresses in the backtrace and not function names. http://psankar.blogspot.com/2010/11/detecting-memory-leaks-in-kernel.html comm "insmod", pid 1559, jiffies 4294961804 (age 229.610s) hex dump (first 32 bytes): fa 3e 00 00 00 00 00 00 92 5a 00 00 00 00 00 00 .>.......Z...... 0a 00 00 00 12 00 00 00 3c 38 00 00 00 00 00 00 ........<8...... backtrace: [<ffffffff8156eb1d>] kmemleak_alloc+0x2d/0x60 [<ffffffff81152469>] __vmalloc_node+0xc9/0xe0 [<ffffffff8115280c>] vmalloc+0x2c/0x30 [<ffffffffa0099047>] 0xffffffffa0099047 [<ffffffffa009906c>] 0xffffffffa009906c [<ffffffff8100204c>] do_one_initcall+0x3c/0x1a0 [<ffffffff810cea1b>] sys_init_module+0xbb/0x200 [<ffffffff81041072>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff On Wed, Oct 27, 2010 at 12:24 PM, Sankar P <sankar.curiosity@gmail.com>wrote:
Hi Dave, Rajat, Mulyadi and everyone,
Thanks for your pointers.
Now I removed the "static __init" from the hello_init function and I got an output of:
unreferenced object 0xf9042000 (size 512): comm "insmod", pid 12068, jiffies 13995923 (age 51.096s) hex dump (first 32 bytes): 6f 64 75 6c 65 00 00 00 00 00 00 2e 73 79 6d 74 odule.......symt 61 62 00 2e 73 74 72 74 61 62 00 2e 73 68 73 74 ab..strtab..shst backtrace: [<c10b0001>] create_object+0x114/0x1db [<c148b4d0>] kmemleak_alloc+0x21/0x3f [<c10a43e9>] __vmalloc_node+0x83/0x90 [<c10a44b9>] vmalloc+0x1c/0x1e [<f9036021>] init_module+0x21/0x2f [hello_kernel] [<c1001226>] do_one_initcall+0x71/0x113 [<c1056c48>] sys_init_module+0x1241/0x1430 [<c100284c>] sysenter_do_call+0x12/0x22 [<ffffffff>] 0xffffffff
And, if I create a new function named myfunc and do my allocations inside that function (instead of the init function), even though I have a "static __init" text in the init_function I get an output:
unreferenced object 0xf9061000 (size 512): comm "insmod", pid 12750, jiffies 14401507 (age 110.217s) hex dump (first 32 bytes): 1c 0f 00 00 01 12 00 00 2a 0f 00 00 01 12 00 00 ........*....... 38 0f 00 00 01 12 00 00 bc 0f 00 00 01 12 00 00 8............... backtrace: [<c10b0001>] create_object+0x114/0x1db [<c148b4d0>] kmemleak_alloc+0x21/0x3f [<c10a43e9>] __vmalloc_node+0x83/0x90 [<c10a44b9>] vmalloc+0x1c/0x1e [<f9055021>] myfunc+0x21/0x23 [hello_kernel] [<f9058012>] 0xf9058012 [<c1001226>] do_one_initcall+0x71/0x113 [<c1056c48>] sys_init_module+0x1241/0x1430 [<c100284c>] sysenter_do_call+0x12/0x22 [<ffffffff>] 0xffffffff
As we can see from the above output, it shows both the function name as well as the module name where the leak is happening. Also the address of the statement. So, my problem seems to be solved. Thank you all for your pointers.
Sorry for the top post and long contents.
On Thu, Oct 28, 2010 at 12:00 AM, Rajat Sharma <fs.rajat@gmail.com> wrote:
try removing static __init from function definition On Wed, Oct 27, 2010 at 10:40 PM, Sankar P <sankar.curiosity@gmail.com> wrote:
Hi,
I have an out of tree kernel module with the source:
static __init int hello_init(void) { char *ptr; ptr = vmalloc(512); ptr = vmalloc(512); ptr = vmalloc(512);
printk(KERN_ALERT "Hello World");
return 0; }
Now I compile this file (hello.c) using my Makefile as follows:
EXTRA_CFLAGS=-g obj-m := hello-kernel.o hello-kernel-objs := hello.o
Now if I insmod my hello-kernel.ko file and then do a `cat /sys/kernel/debug/kmemleak` I get an output:
unreferenced object 0xf8211000 (size 512): comm "insmod", pid 9602, jiffies 3666022 (age 1553.469s) hex dump (first 32 bytes): 01 12 00 00 f2 10 00 00 01 12 00 00 fe 10 00 00 ................ 01 12 00 00 0c 11 00 00 01 12 00 00 1a 11 00 00 ................ backtrace: [<c10b0001>] create_object+0x114/0x1db [<c148b4d0>] kmemleak_alloc+0x21/0x3f [<c10a43e9>] __vmalloc_node+0x83/0x90 [<c10a44b9>] vmalloc+0x1c/0x1e [<f8208021>] 0xf8208021 [<c1001226>] do_one_initcall+0x71/0x113 [<c1056c48>] sys_init_module+0x1241/0x1430 [<c100284c>] sysenter_do_call+0x12/0x22 [<ffffffff>] 0xffffffff
I understand that the kmemleak has correctly detected the memory leak. But why is the leak showing in insmod , instead of the actual function name "hello_init". Is there a way we can get the exact location inside the hello.c file printed instead of the generic "insmod" location ?
If I do a `gdb hello-kernel.ko`, the symbols are properly resolved, so I am sure the .ko file has symbols.
Any help will be appreciated. Thank you.
-- Sankar P http://psankar.blogspot.com
-- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
-- Sankar P http://psankar.blogspot.com
-- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
-- Regards, S. Sengottuvelan.
Hi... On Thu, Dec 23, 2010 at 04:44, Sengottuvelan S <sengottuvelan.s@gmail.com> wrote:
comm "insmod", pid 1559, jiffies 4294961804 (age 229.610s) hex dump (first 32 bytes): fa 3e 00 00 00 00 00 00 92 5a 00 00 00 00 00 00 .>.......Z...... 0a 00 00 00 12 00 00 00 3c 38 00 00 00 00 00 00 ........<8...... backtrace: [<ffffffff8156eb1d>] kmemleak_alloc+0x2d/0x60 [<ffffffff81152469>] __vmalloc_node+0xc9/0xe0 [<ffffffff8115280c>] vmalloc+0x2c/0x30 [<ffffffffa0099047>] 0xffffffffa0099047 [<ffffffffa009906c>] 0xffffffffa009906c [<ffffffff8100204c>] do_one_initcall+0x3c/0x1a0 [<ffffffff810cea1b>] sys_init_module+0xbb/0x200 [<ffffffff81041072>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff
Fairly likely, it's either: a. Stack frame is corrupted or b. the area isn't so near of any recorded symbol -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
participants (2)
-
Mulyadi Santosa -
Sengottuvelan S