lkml.org 
[lkml]   [2006]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Some issues about the kernel memory leak detector: __scan_block() function
Hi Catalin,

On 8/17/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> Hi Mauricio,
>
> On 16/08/06, Mauricio Lin <mauriciolin@gmail.com> wrote:
> > Let's suppose the a kmalloc() was executed without storing the
> > returned pointer to the memory area and its fictitious returned value
> > would be the address 0xb7d73000 as:
> >
> > kmalloc(32, GFP_KERNEL); // Cause memory leak
> >
> > Is there any possibility the __scan_block() scans a memory block that
> > contains the memory area allocated by the previous kmalloc?
>
> That's what the memleak-test module does.
>
> Yes, there is a chance and this is called a false negative. If there
> is a (non-)pointer location having this value (especially the stack),
> it won't be reported. However, these locations might change and at
> some point you will get the leak reported.

Do you mean that the (non-)pointer location might be moved to another
memory location?

Let's say that the fictitious address 0xb7d73000 can be changed to
another memory address, right?

BR,

Mauricio Lin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-17 16:05    [W:0.108 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site