Messages in this thread | | | Date | Tue, 28 Oct 1997 12:21:18 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: [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
| |