On Fri, Sep 08, 2006 at 10:07:53AM -0400, James Stark wrote: > >A process doesn't use any memory after it's done; the memory is freed by > >the > >kernel. If not, that would be a kernel bug.
> Usually that's true, however there have been cases where the kernel has > bled memory like that the the blame was put on the process. So is > updatedb the cause, or just the trigger that exposes the bug? If you > really think that it's a kernel bug then feel free to reassign it. If there is no process left associated with that memory, it's definitely a kernel bug. If updatedb leaves a process around and that's what uses the memory, that's an updatedb bug. > >But how have you determined that the memory is "in use"? It sounds to me > >like you're misidentifying disk cache as "used" memory. > Nope. Disk cache is reported separately. Here is the results from > another run designed to reproduce the problem. It was run on an AthonXP > with 512MB of RAM, running up to date unstable and stock 2.6.17. I had > killed off everything except udev, syslog, init and the kernel processes: > # uname -a > Linux Barracuda 2.6.17-2-k7 #1 SMP Thu Aug 31 13:27:53 UTC 2006 i686 > GNU/Linux > # ps ax [...] > # updatedb Ok; what does ps ax show /after/ you've run updatedb? That seems to be the key. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
