Strange memory leak
Konstantin Schauwecker
I'm currently programming a server application. The problem is: Everytime a
client connects, the VM size grows of about 2 MB (as ksysguard tells me)
and it doesn't reduce after the client disconnects. I completely analyzed
my software with valgrind (a memory debugger) and removed all leaks, but it
didn't change the situation. The only explanations I have, is that I
allocate some memory which gets freed at the end of the program (but I had
a close look to all my destructors) or, and this is the reason why I'm
posting, perhaps Linux doesn't free the memory immediatly (for some
optimisation). Would be great if someone could answer me this question or
give me another possible reason.
Konstantin Schauwecker
Sven Vermeulen
Linux doesn't free it immediately since it thinks that it could be used later
on again. You shouldn't worry about this, it wont stay in the RAM forever:
when another process requires memory and there isn't enough free space in the
RAM anymore, the "reserved" memory will be swapped out or even free'd.
Linux first fills the RAM (because it's useless to free space in RAM if there
is still space left), then tries to swap out the correct pages (using page
aging algorithms) if memory is required.
Wkr,
Sven Vermeulen
--
Fighting for peace is like fucking for virginity.
Nils O. Selåsdal
it only gives memory back to the process for reuse.
If your program increases 2MB _every_ time, and thus eventually grows
to hundreds of MB, its another problem though.
--
Vennlig hilsen/Best Regards
Nils Olav Selåsdal
System Engineer
UtelSystems a/s
Kasper Dupont
>
> On Sun, 29 Dec 2002 13:34:10 +0100, Konstantin Schauwecker
> <h...@konstantin-schauwecker.de> wrote:
> > I'm currently programming a server application. The problem is: Everytime a
> > client connects, the VM size grows of about 2 MB (as ksysguard tells me)
> > and it doesn't reduce after the client disconnects. I completely analyzed
> > my software with valgrind (a memory debugger) and removed all leaks, but it
> > didn't change the situation. The only explanations I have, is that I
> > allocate some memory which gets freed at the end of the program (but I had
> > a close look to all my destructors) or, and this is the reason why I'm
> > posting, perhaps Linux doesn't free the memory immediatly (for some
> > optimisation). Would be great if someone could answer me this question or
> > give me another possible reason.
>
> Linux doesn't free it immediately since it thinks that it could be used later
> on again.
It is correct that the malloc implementation in glibc does so. But I'm
pretty sure Linux itself doesn't do that. And even if the growing size
is caused by glibc keeping memory allocated, it shouldn't continue
growing. The memory kept by glibc is supposed to be reused by later
calls of malloc. And IIRC this behaviour is only used for allocations
smaller than 128KB. For 128KB and more a buffer is allocated directly
with mmap and freed imediately.
> You shouldn't worry about this, it wont stay in the RAM forever:
> when another process requires memory and there isn't enough free space in the
> RAM anymore, the "reserved" memory will be swapped out or even free'd.
It can be swapped out, but I don't see how it could possibly be freed.
AFAIK there is no way the kernel can tell glibc to reduce memory usage.
And just swapping out is not a good idea, we don't want to waste time
writing unneeded data to the disk, neither do we want to waste swap
space until the process terminates.
>
> Linux first fills the RAM (because it's useless to free space in RAM if there
> is still space left), then tries to swap out the correct pages (using page
> aging algorithms) if memory is required.
All of that applies to mmaped files being cached. But it surely
doesn't apply to memory being freed by a process. In fact that is one
of the ways you can force Linux to have a lot of free RAM. Allocate a
lot of address space, use it, and finally free it. You will at this
point see a lot more free space than during normal use.
Sure Linux keeps diskblocks in memory if it is not needed for anything
else, but it does so because they can turn out to be usefull later.
Memory freed by a process is never going to be of any use again, so it
is indeed returned immediately to the pool of free pages.
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);
Paul Pluzhnikov
> The problem is: Everytime a
> client connects, the VM size grows of about 2 MB (as ksysguard tells me)
> and it doesn't reduce after the client disconnects. I completely analyzed
> my software with valgrind (a memory debugger) and removed all leaks, but it
> didn't change the situation.
One way to write a (buggy) server program with the symptoms you
describe is to have the server allocate large amount of per-client
state (create a new thread, mmap() an I/O buffer, etc.) and then
"hold on" to it, e.g. save the buffer in a global map.
Technically this is not a leak, and the memory *will* be released
when the global map is destructed. Such memory often does not
show up in 'leak checker' reports.
The good news: such bugs are usually quite easy to find, if you know
what per-client state you are allocating.
If you don't, you may want to take a look at 'InUse' (part of
Insure++, http://www.parasoft.com), which has several ways of
looking at the memory use behaviour of a program in execution.
Cheers,
--
In order to understand recursion you must first understand recursion.
Kasper Dupont
>
> Most OSes dont give back allocated memory to the OS when memory is freed,
> it only gives memory back to the process for reuse.
More precisely glibc does not give all the memory back to Linux
immediately. AFAIK it only keeps the memory if it is allocations
of less than 128KB.
> If your program increases 2MB _every_ time, and thus eventually grows
> to hundreds of MB, its another problem though.
If memory is kept by glibc it is supposed to be reused. Not
releasing all memory the first time might be normal, but it is
certainly not supposed to keep growing. If the memory usage was
converging towards a constant usage, I wouldn't consider it a
problem. But if it keeps growing there is probably some leak.
Kasper Dupont
>
> Hello
> I'm currently programming a server application. The problem is: Everytime a
> client connects, the VM size grows of about 2 MB (as ksysguard tells me)
> and it doesn't reduce after the client disconnects.
What ksysguard tell you is not how much memory the process has
allocated, but rather how much of the allocated memory has yet
been used. The actual amount of allocated memory as can be
computed from /proc/%d/maps is probably a better indication of
what is going on in your program. Is the size in fact growing
by 2MB after every client, or does the grow slow down? What is
the exact usage before the first client, before the second
client, before the third, and so on?
> (but I had
> a close look to all my destructors) or, and this is the reason why I'm
> posting, perhaps Linux doesn't free the memory immediatly (for some
> optimisation).
What language are you using? Destructors sounds like some kind
of objectoriented language. If the memory usage keeps growing
I'd try an ABRT signal to see what the core dump contains.
Could give some indication to what kind of data is being kept.
Konstantin Schauwecker
> What ksysguard tell you is not how much memory the process has
> allocated, but rather how much of the allocated memory has yet
> been used. The actual amount of allocated memory as can be
> computed from /proc/%d/maps is probably a better indication of
> what is going on in your program. Is the size in fact growing
> by 2MB after every client, or does the grow slow down? What is
> the exact usage before the first client, before the second
> client, before the third, and so on?
I made the test again with ksysguard (I'm already to tired to take a closer
look on /proc/%d/maps *g*). Here are the sizes ksysguard tells me:
No client: 3980 KB
1. connection: 6172 KB
2. connection: 8220 KB
3. connection: 10268 KB
4. connection: 12316 KB
It doesn't seem to reduce. I once made it up to 30 MB ;-)
> What language are you using? Destructors sounds like some kind
> of objectoriented language. If the memory usage keeps growing
I wrote the server in c++.
> I'd try an ABRT signal to see what the core dump contains.
> Could give some indication to what kind of data is being kept.
Well, how can I watch the core dump?
Artie Gold
Just a SWAG:
Are you creating a thread every time a client connects?
Are you joining those threads when a client disconnects?
That could be what's going on.
HTH (and I won't be offended if it doesn't ;-)),
--ag
--
Artie Gold -- Austin, TX
ag...@bga.com
"May you keep turning the pages. And may the book never end."
Kasper Dupont
>
> Kasper Dupont wrote:
>
> > I'd try an ABRT signal to see what the core dump contains.
> > Could give some indication to what kind of data is being kept.
>
> Well, how can I watch the core dump?
Type "kill -SIGABRT pid" in your shell to make the process dump.
First ensure that the process will in fact be able to produce a
core dump, take a look here to see what can go wrong:
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#core
When you have the core file, look in the contents to see if
there are large amounts of data you can somehow recognize.