lkml.org 
[lkml]   [2009]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Leaks in trace reported by kmemleak
    From
    Date
    On Mon, 2009-10-19 at 11:15 +0200, Zdenek Kabelac wrote:
    > 2009/10/16 Catalin Marinas <catalin.marinas@arm.com>:
    > > On Fri, 2009-10-16 at 17:07 +0200, Zdenek Kabelac wrote:
    > >> So I've tested this modified version and it gives much better result
    > >> with respect to amount of leaked objects
    > >
    > > BTW, I created this tree with kmemleak patches to be pushed upstream:
    > >
    > > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/kmemleak.git
    > >
    > > It would be easier to test.
    >
    > Yes this branch worked well - and there were no leaks from i915 or
    > kvm modules for trace.
    >
    > What is however interesting is the false positive leak for
    > dma_debug_init(). Which is sometimes listed and sometimes not - the
    > memory is allocated just once in the code during boot, so it's strange
    > that pointers to that area are sometimes out of kmemleak scan.

    I updated the tree above with another patch which lists where an object
    is referred from. So when you get a leak reported and it later
    disappears, you can use:

    echo dump=0x... > /sys/kernel/debug/kmemleak

    and in syslog you can find information about the previously reported
    object and where it is referred from (if it is no longer reported as a
    leak). I'm not sure whether this option would be useful for anything
    other than debugging kmemleak. I still aim on getting to near 0 false
    positives.

    Anyway, trying this new patch on the debug_objects, when no longer
    reported they are referred from obj_hash. My opinion is that they were
    moved to obj_hash during the kmemleak scanning but after kmemleak
    finished scanning the data section, hence they couldn't be found.

    I hoped that not reporting object allocated within the last 5s would
    avoid such problems but there are places like debug_objects for which it
    doesn't work as the objects were reported earlier.

    A workaround I had in the past was to not report an object unless it was
    found as a leak in two consecutive scans. I should probably reinstate
    this feature (could be optimised to use a second prio_tree containing
    only objects found as leaks).

    --
    Catalin



    \
     
     \ /
      Last update: 2009-10-19 14:03    [W:0.023 / U:0.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site