public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bob McElrath <bob+debian-alpha@mcelrath.org>
To: mcompengr@earthlink.net
Cc: debian-alpha@lists.debian.org, linux-kernel@vger.kernel.org
Subject: Re: alpha kernel memory leak
Date: Thu, 15 May 2003 10:45:47 -0500	[thread overview]
Message-ID: <20030515154546.GA19041@mcelrath.org> (raw)
In-Reply-To: <3EC374D0.53602A1@earthlink.net>

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

mcompengr@earthlink.net [mcompengr@earthlink.net] wrote:
> 
> (Please correct me where I'm wrong.)
> 
> Generally, a memory leak is where an often called piece of code
> dynamically allocates itself some memory for temporary usage, and
> then fails to release that memory before being called again.
> 
> This situation might be indicated by running out of swap space, at
> which point the machine should grind to a halt (all processes), but
> the memory usage reflected by the "top" or "free" commands won't show
> it.  Swap space should be twice the size of physical memory.

The machine does, in fact grind to a halt.  When I first boot the memory
usage is ~250MB and I have no problems using or starting any program.

After a few days the memory usage is ~500MB and I cannot start programs
(they are killed immediatly with OOM).  Note that in both cases the SAME
programs are running.  Just sitting here and watching 'top' shortly
after bootup, the memory usage goes up by ~2k/s.  This is with the
network down, so the machine should be quiescent and hopefully no memory
allocations taking place.  I just checked again with all services
stopped and the network down, at the console (no X), only init, tcsh and
my little perl memory logging script running.  It still leaks by 1.8k/s,
according to my calculations.

If I turn swap back on, most operations cause a massive amount of
swapping (switching desktops in X).

Are there any tools to examine how memory is being used, that report
sensible numbers?  As I mentioned 'ps' no longer reports any memory
numbers (procps 3.1.8, debian unstable).  And using top, the sum of VIRT
is never equal to 'used'.  If there is a memory leak, how do I determine
that definitively?

Cheers,
Bob McElrath [Univ. of Wisconsin at Madison, Department of Physics]

    "You measure democracy by the freedom it gives its dissidents, not the
    freedom it gives its assimilated conformists." -- Abbie Hoffman


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2003-05-15 15:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-13 15:13 alpha kernel memory leak Bob McElrath
     [not found] ` <3EC374D0.53602A1@earthlink.net>
2003-05-15 15:45   ` Bob McElrath [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-15 11:10 mcompengr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030515154546.GA19041@mcelrath.org \
    --to=bob+debian-alpha@mcelrath.org \
    --cc=debian-alpha@lists.debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcompengr@earthlink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox