Re: Exact leak location in KMemleak Output

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
> try removing static __init from function definition
> On Wed, Oct 27, 2010 at 10:40 PM, Sankar P <sankar.curiosity@xxxxxxxxx>
> 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@xxxxxxxxxxxx
>> 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@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




--
Regards,
S. Sengottuvelan.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux