lkml.org 
[lkml]   [1997]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [repost?] idea for catching memory leaks

On Mon, 27 Oct 1997, Nathan Bryant wrote:

> here's a simple idea for catching memory leaks: modify kmalloc() so that
> it examines its call frame and tags each chunk of memory with the address
> kmalloc() was called from. i'd be surprised if nobody has thought of
> something like this before; has anyone done patches for that sort of
> thing?


a similar patch was sent to linux-kernel a few weeks ago, but it was buggy
so i fixed/modified it. (this is the reasonn why i sent those few 'memory
leak fix' patches recently). It not only traces kmalloc()/kfree(), but
also get_free_pages()/free_pages(), plus on demand it can be extended to
the skb_alloc()/skb_free() interface as well. (but my system has no
skbuff.c leak, so i had no reason to do so) [i will send the new patch to
this list soon]

the patch maintains per allocation point allocation counts (thus suits
leak tracing perfectly). A constantly rising allocation count usually
means a memory leak.

it is important to have per allocation-point statistics, per-allocation
statistics takes away too much kernel memory in RL systems. (eg. there are
tens of thousands of active allocations in a moderately busy server)

-- mingo


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.861 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site