[lkml]   [2003]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.0-test5/6 (and probably 7 too) size-4096 memory leak
    William Lee Irwin III <> wrote:
    > Alberto Bertogli <> wrote:
    > >> Slabinfo reports that size-4096 has 104341 active objects and growing.
    > >> On another box at home I see the same issue with test6, but "only" with
    > >> 11612 objects; I'm not posting info on this box as I guess the mailserver
    > >> is much more important because the leak is really noticeable.
    > On Wed, Oct 15, 2003 at 09:19:18PM -0700, Andrew Morton wrote:
    > > At least I'm not the only one; my main desktop machine does the same
    > > thing. It leaks two megabytes a day into size-4096, like clockwork. It's
    > > up to 43 megs now.
    > > I was ignoring it and hoping it would go away. Ho hum. Tricky.
    > I immediately thought of bundling this in with the do_exit() BUG() and
    > /proc/ oopsen, but we would see a task_t leak also in that case. I still
    > say the /proc/ change is swiss cheese (well, in concept there's nothing
    > wrong with what it wants to do, but there's something definitely wrong
    > with the implementation since backing it out stops things from oopsing),
    > but this looks unrelated therefore (which is actually depressing, since
    > we can't kill all three in one shot and/or get anywhere by correlating).
    > I should try using a dedicated stack slab to see if they're stacks even
    > though task_t's aren't leaking.

    This leak is at least a couple of months old.

    The recent (test7) /proc oops was fixed when Linus reverted the
    job-control-in-signal-struct patch.

    This leak is of size-4096: it isn't kernel stacks.

    I did a quicky audit of all kmalloc(PAGE_SIZE) instances and everything
    looked OK: one suspect in the NFS server but I wasn't able to force
    speedier bloat by exercising the NFS server in my normal usage pattern.

    I'm thinking we need to stuff builtin_return_address(0) into the object and
    write a dumper, but I haven't looked into that. Maybe I can persuade
    Manfred to cook up a custom patch to do that? Just for size-4096? Something
    really crude will be fine.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.228 / U:0.020 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site