lkml.org 
[lkml]   [2008]   [Dec]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/14] Kernel memory leak detector
    From
    Date
    On Mon, 2008-12-29 at 16:23 -0800, Andrew Morton wrote:
    > What is the track record of this code? Has it found many leaks? Do
    > we expect that it will find sufficient leaks of sufficient importance
    > to justify kmemleak's inclusion and maintenance?

    It found a few leaks not found by static code analysis (not many though)
    but I mainly tested it on small embedded systems. I think it may be
    better to include it in the -mm tree for a while so that more people
    test it before deciding whether to merge it into mainline.

    FYI, here are some past reports:

    http://lkml.org/lkml/2006/5/28/37
    http://lkml.org/lkml/2006/7/10/370
    http://lkml.org/lkml/2006/8/10/207
    http://lkml.org/lkml/2006/8/12/11
    http://lkml.org/lkml/2006/8/19/44
    http://lkml.org/lkml/2006/12/9/178
    http://lkml.org/lkml/2006/12/9/176
    http://lkml.org/lkml/2007/3/8/222
    http://lkml.org/lkml/2008/11/19/204

    > I'm a little doubtful personally. We often fix leaks, and they are
    > almost always things which nobody noticed at runtime, and which were
    > found by code inspection or source-code checking tools. And they're
    > usually leaks which nobody would care about much anyway?

    I'm a bit biased to comment on the usefulness of kmemleak :-). Anyway,
    AFAIK static code checking tools (like coverity) are good for relatively
    simple things like not freeing on an error return path (maybe they can
    go further across multiple files, I haven't tried it). I doubt such
    tools can catch leaks caused by incorrect reference counting or very
    complex code. OTOH, kmemleak doesn't report a leak unless it occurred,
    so static and dynamic checking tools are rather complementary.

    Now, as long as the code is correctly written and with additional static
    checking, kmemleak shouldn't find a significant number of bugs. However,
    some (earlier) bugs mentioned above were causing tens of (small) leaks
    in a few minutes. They may have become visible after days of running but
    it's much easier to catch and fix them early.

    You can't really tell whether a leak is serious or not until you check
    the code. A leak doesn't necessarily mean that you can no longer reuse a
    block of memory but the code possibly frees a different one still in use
    by other parts of the kernel (e.g. the last report mentioned above).

    --
    Catalin



    \
     
     \ /
      Last update: 2008-12-30 12:47    [W:0.022 / U:59.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site