Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-04 Thread Andrew Morton
Justin Schoeman <[EMAIL PROTECTED]> wrote: > > Will the slab debugger make it into the kernel as a standard compile > time option? It is a _really_ usefull tool to have around. It has a slight downside: it unconditionally changes the type of kmem_bufctl_t to unsigned long, which wastes two or f

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-03 Thread Justin Schoeman
Thanks everybody for your help. I have at least located the site of the leak - now I just need to find out why the destructor is not being called ;-). Will the slab debugger make it into the kernel as a standard compile time option? It is a _really_ usefull tool to have around. Thanks again,

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-03 Thread Andrew Morton
Justin Schoeman <[EMAIL PROTECTED]> wrote: > > OK - I have the patch working now, but there seems to be a flaw in the > address reporting. When I look up the reported address in > /proc/kallsyms, then look in the objdump of the module, the reported > adress _does_not_ point to a call. > > A

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-03 Thread Justin Schoeman
OK - I have the patch working now, but there seems to be a flaw in the address reporting. When I look up the reported address in /proc/kallsyms, then look in the objdump of the module, the reported adress _does_not_ point to a call. Am I missing something simple here? Justin Andrew Morton wrote

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread Manfred Spraul
Andrew Morton wrote: OGAWA Hirofumi <[EMAIL PROTECTED]> wrote: Andrew Morton <[EMAIL PROTECTED]> writes: > + slab_bufctl(slabp)[objnr] = (unsigned long)caller; Umm... this patch looks strange.. slab_bufctl() returns "kmem_bufctl_t *", but kmem_bufctl_t is "unsigned short". Good poi

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread Andrew Morton
OGAWA Hirofumi <[EMAIL PROTECTED]> wrote: > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > + slab_bufctl(slabp)[objnr] = (unsigned long)caller; > > Umm... this patch looks strange.. > > slab_bufctl() returns "kmem_bufctl_t *", but kmem_bufctl_t is > "unsigned short". Good point.

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread OGAWA Hirofumi
Andrew Morton <[EMAIL PROTECTED]> writes: > + slab_bufctl(slabp)[objnr] = (unsigned long)caller; Umm... this patch looks strange.. slab_bufctl() returns "kmem_bufctl_t *", but kmem_bufctl_t is "unsigned short". I guess that this debug patch was broken by something else... -- OGAWA

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread Alexander Nyberg
> I am having a problem with memory leaking on a patched kernel. In order > to pinpoint the leak, I would like to try to trace the allocation points > for the memory. > > I have found some vague references to patches that allow the user to > dump the caller address for slab allocations, but I

Re: Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread Andrew Morton
Justin Schoeman <[EMAIL PROTECTED]> wrote: > > I am having a problem with memory leaking on a patched kernel. In order > to pinpoint the leak, I would like to try to trace the allocation points > for the memory. > > I have found some vague references to patches that allow the user to > dum

Tracing memory leaks (slabs) in 2.6.9+ kernels?

2005-03-02 Thread Justin Schoeman
Hi, I am having a problem with memory leaking on a patched kernel. In order to pinpoint the leak, I would like to try to trace the allocation points for the memory. I have found some vague references to patches that allow the user to dump the caller address for slab allocations, but I cannot f