[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#680550: linux-image-2.6.32-5-amd64: kmalloc-32 memory leak for kernel 2.6.32-5-amd64

On Sat, 2012-07-21 at 21:04 -0700, Alan W. Irwin wrote:
> On 2012-07-21 23:24+0100 Ben Hutchings wrote:
> > Thanks to the detailed report.  Memory leaks are sadly common, and many
> > have been fixed since Linux 2.6.32.  I don't think it's practical to
> > attempt to match up those many fixes against your list of applications.
> Hi Ben:
> Thanks for responding.
> Could you please attempt to verify the problem (by periodically
> checking kmalloc-32 in /proc/slabinfo on machines you have access to
> for a few days) to get a feel for how common this issue is?

It seems like there should normally be < 10,000 active kmalloc-32
objects, whereas with this bug there will soon be many more than that.
So I'll just look to see where that is the case.

My own sample of 1 server doesn't have this problem:

$ cat /proc/version
Linux version 2.6.32-5-486 (Debian 2.6.32-45) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sun May 6 03:29:22 UTC 2012
$ uptime
 05:50:10 up 46 days,  5:15,  6 users,  load average: 0.16, 0.73, 0.97
$ grep kmalloc-32 /proc/slabinfo
kmalloc-32          2640   2944     32  128    1 : tunables    0    0    0 : slabdata     23     23      0

> For
> example, it might occur for _all_ desktop users who run
> kernel-2.6.32-5-amd64 and not have much to do with my own particular
> application mix.  After all, this is not an ordinary memory leak.
> Instead, it is a leak in a special kind of memory that the kernel
> controls directly, and presumably this kernel bug is exercised by just
> some subset of the normal kernel calls.

It is almost certainly rather more subtle than that, and may be
associated with a particular filesystem or driver.

> Of course, that computer essentially runs nothing but an X server so
> that is a very limited application mix and a heavier application mix 
> might trigger the issue.  On the other hand, the problem might be
> limited just to 64-bit hardware.  So monitoring /proc/slabinfo on both
> 32-bit and 64-bit machines running 2.6.32 is required to help pin this down.

Possible.  I don't have any 64-bit systems running the 'squeeze' kernel
based on Linux 2.6.32 any more.  But I can check various Debian
developer machines:

busoni (amd64): no
cilea (amd64): no
paganini (amd64): no
piatti (amd64): no
popov (amd64): no
powell (amd64): no
ravel (amd64): no
respighi (amd64): no
ries (amd64): no
stabile (amd64): no

And a few other architectures:

master (i386): no
samosa (i386): no
senfl (i386): no
widor (i386): no
agricola (armel): no
smetana (sparc): no
zelenka (s390): no


Ben Hutchings
73.46% of all statistics are made up.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: