I have a c program running on linux .
the program is supposed to run forever .
inside the code , there are malloc() and free() called to allocate memory and free them.
I used valgrind to check, no memory leak occured .
However ,when the program is running , I use gneom-system-monitor to watch the memory , the sise of taken memory is growing bigger and bigger and never decreased a little bit.

I googled online, some said ,though the program freed memory , but it does not return to system immidiately instead, it is kept in the application for reuse. when the program terminated, the memory then return to system.

I want to know if it is correct,
and if so , why the size of taken memory keep increasing .

Could you tell me
1, how to let the freed memory return to system for reuse immidiately
2, if the freed memory is kept in applition for reuse, how can I let the genom-system-monitor find the real number of taken memory



Thanks in advance.

Rui

Have a look at the man page for malloc ( /usr/share/man/man3/malloc.3 ) It doesn't say any such thing, some linux programs are run continuously for long periods of time and don't suffer this problem I would say you have another memomry leak somewhere, of course I could be wrong!

Hello, thanks for reply.
I did some test about memory allocation and free , and understand how it works in linux .
when freed memory , the memory will not return to system ,instead it will be kept in this process for reuse. when allocating memory next time , the memory will be used first, then if it is not enough, apply for more memory again system.

my issue is still there , the c program has been running for years on unix, and never have this issue( the occupied memory becomes bigger and bigger ), now I migrate it to linux , the issue appeared .

anybody could shed any light on this

Thanks.
Rui

That is correct.

I would need at lot more details to even make a guess.

Over a certain chunk size (which I think is hard wired inside malloc) memory is returned as soon as it is freed.

For small chunks, it really isn't practical to return memory to the system when freed.

Some operations in some programs allocate a very large number of small chunks for the duration of the operation (but much less than the duration of the program) and then free ALL of those small chunks at the end of the operation. In that case, it is more efficient (though much more complicated) to set up your own pool allocator for those small chunks: Grab one or more giant chunks from malloc (big enough they will be returned to the OS when freed) and subdivide those into the smaller chunks you need. C++ has special features to make that easier. In C it needs larger changes to your program, but is still practical.

You can't.

That is hard to guess without more info on the allocation and free patterns and the time scale and the growth scale.

Memory may get fragmented as chunks of varying sizes are allocated and freed in a complex pattern, so the total usage by the process from the viewpoint of the system can grow for a long time while the total usage by the program from its own point of view is fairly stable. That effect is not unbounded. At some point the new allocations start fitting consistently into the previous fragments and the process size stops growing.

But if you have an actual memory leak in the program, rather than a fragmentation effect, it could grow until you stop it.

1 members found this post helpful.

Thanks.
I am sure it is a memory leak .
The program uses a for loop and sleep() to run forever .
After each iteration , the occupied memory grow a little bigger .

The thing is that it runs well on unix rather than on Linux ,so there must be some difference between unix and linux that causes the issue .

Thanks again for your kindness . Johnsfine.

Rui

One place I have found memory leaking (slowly) is in the use of file descriptors.

A fopen will allocate more memory...An fclose CAN release it. However, it depends on the system if what actually gets used is freopen. Different systems can do different things, and there could be a bug in freopen/fdopen as it isn't used that often.

The leak I detected was my own (I forgot to close the file), but every time it was by 4K.

1 members found this post helpful.

Thanks Jpollard,
it helps.

Rui