Re: How to analyze kmemleak message?
From: Tetsuo Handa
Date: Mon Feb 23 2009 - 06:29:18 EST
Hello.
Thank you for explanation.
Catalin Marinas wrote:
> As Pekka said, they refer to the place where the object was allocated.
OK. The trace shows where that memory was allocated.
> This object can no longer be found to be referred by other objects or
> from the data section, hence it is assumed to be a leak (it could, as
> well, be a false positive, transient or not).
Kmemleak scans all data section for addresses returned by kmalloc() etc.
void *p1;
void foo(void)
{
void *p2 = kmalloc(1, GFP_KERNEL);
p1 = kmalloc(1, GFP_KERNEL);
}
"p1" will be reported by default.
To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .
Is this correct?
> Basically, you need check
> where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
> stored and whether it can still be referred from that place (or a
> different one) later.
>
> Kmemleak tries to avoid the reporting of transient leaks by only
> reporting objects with a life time of more than 5 seconds.
kjournald's commit interval (default to 5 sec?) + a few seconds
might be better. (No reason. Just my feeling.)
> To make sure
> the reports you got aren't transient leaks, you can read
> the /sys/kernel/debug/kmemleak file a few times to see whether they
> disappear.
Well, I couldn't check /sys/kernel/debug/kmemleak etc. because
I couldn't reach login prompt.
> There is a Documentation/kmemleak.txt file where you may find some
> useful information.
I see.
I have a question. My module uses kmalloc(PATH_MAX, GFP_KERNEL) which
won't be released by kfree(). I count up how many bytes are allocated but
I don't want kmemleak to report such memory as memory leaks.
Can I do so by
void bar(void)
{
static void *p;
if (!p) {
p = kmalloc(PATH_MAX, GFP_KERNEL);
kmemleak_not_leak(p);
}
...
}
(or kmemleak_ignore() (which one to use and how to use))?
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/