Memory leak in C

aztroboy · 12-07-2010, 06:58 PM

I'm doing some raw socket scripting in C. Everything works fine.

However, I monitored the memory using top, and it shows that the memory used by my script is increasing over time.

I don't have that many mallocs (maybe a couple), but lots of pointers. Even though I free those pointers (used as local variables in functions), the memory used by my program is still consuming memory (although slower than if free() is not being used).

I would like to know what situations may produce memory leak and how to deal with them. Do the char[] variables need to be freed?

I'm just asking for some guidelines.

Thank you

neonsignal · 12-07-2010, 11:38 PM

In general, every piece of memory that is malloced should eventually be freed. But you should not free memory that was not allocated from the heap.

However, you can also have 'leaks' if you do not free system resources (for example, you may be failing to close open sockets that are no longer being used).

Valgrind can be useful for finding leaks if you get really stuck.

Aquarius_Girl · 12-07-2010, 11:40 PM

Quote:

But you should not free memory that was not allocated from the heap.

Shouldn't the sentence be:
But you cannot free memory that was not allocated from the heap.

Correct me if I am wrong.

neonsignal · 12-07-2010, 11:52 PM

Quote:

Originally Posted by anishakaul

Shouldn't the sentence be:
But you cannot free memory that was not allocated from the heap.

You are correct in the sense that in an environment like glibc, calling free on a pointer that is outside the heap will generate an error. However, the standard simply says that the behaviour is not defined, and in some environments freeing such a chunk of memory not created by alloc or calloc will appear to work (but corrupt the memory around the chunk).

Aquarius_Girl · 12-08-2010, 12:02 AM

Thanks, that was informative but when you say:

Quote:

in some environments freeing such a chunk of memory not on the heap will appear to work (but corrupt the memory around the chunk).

Are you talking about static arrays ? Dynamic memory has to be from heap, isn't it ? Or I am barking at the wrong tree ?

neonsignal · 12-08-2010, 01:22 AM

Quote:

Originally Posted by anishakaul

Are you talking about static arrays ? Dynamic memory has to be from heap, isn't it ?

Yes, I was thinking about arrays declared statically or on the stack.

Aquarius_Girl · 12-08-2010, 02:00 AM

Well I found a nice link on stacks and heaps but:
http://www.learncpp.com/cpp-tutorial...-and-the-heap/

how to manually allocate memory from stack is still a question for me

wagaboy · 12-08-2010, 04:01 AM

Quote:

Originally Posted by aztroboy

However, I monitored the memory using top, and it shows that the memory used by my script is increasing over time.

Which field are you looking in 'top' command ? It (top) does not accurately represent malloc/free. Neither do most monitoring tools like top. It's quite possible that freeing memory may not be reflected in top.

Only tools that directly interact with application can give an accurate view. As neonsignal mentioned, you can use Valgrind, which would be my first choice (I'm a lazy-to-type GUI lover :P), or you could use mtrace (simple, yet effective) to find the source of leaks.

wje_lq · 12-08-2010, 06:16 AM

In the name of the Flying Spaghetti Monster,

Quote:

Originally Posted by anishakaul

how to manually allocate memory from stack is still a question for me

Use alloca(), but:

Returning from the current function is the only way you can free the memory; you can't use free() on memory allocated with alloca().
It's not a good idea to use alloca() for large amounts of memory.
This function is not as portable as one might like.
There are other arcane points of caution. Read about them on the man page.

theNbomr · 12-08-2010, 08:38 AM

There is a smallish class of functions which silently allocate memory, and for which the expectation is that the caller will be responsible to free said memory. The function strdup() is an example of one such function. I'm not sure if there is a way to get a concise list of functions that behave similarly. If in doubt, check the repective man pages for functions you use.

--- rod.

neonsignal · 12-08-2010, 07:34 PM

Quote:

Originally Posted by theNbomr

There is a smallish class of functions which silently allocate memory, and for which the expectation is that the caller will be responsible to free said memory.

Good point; the following are some of the functions that can allocate from the heap:
calloc, malloc
posix_memalign, memalign, valloc
strdup, strndup
wcsdup
asprintf, vasprintf
tempnam
getcwd, get_current_dir_name
realpath
open_memstream
mhash_get_hash_name, mhash_get_keygen_name
pth_sfiodisc

There are others that use malloc and free internally, but the application does not have to explicitly free the memory.

Aquarius_Girl · 12-08-2010, 09:07 PM

wje_lq,

That was helpful, Thanks for the enlightenment!

Quote:

Originally Posted by wje_lq

Returning from the current function is the only way you can free the memory

Well, does this mean the actual return statement will have to be used or the memory will be automatically freed when the scope of the function ends ?

I read this doc: http://www.gnu.org/s/libc/manual/htm...ages-of-Alloca

Spoilsport:

Quote:

The alloca() function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged.

On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca() would appear on the stack in the middle of the space for the function arguments.

smeezekitty · 12-08-2010, 09:43 PM

Memory leaks are very hard to trouble shoot. (especially without code

)

wje_lq · 12-08-2010, 09:44 PM

In the name of the Flying Spaghetti Monster,

No, you don't need the actual return statement for the allocaton to be released.

I'd be curious to see documentation on how it's buggy. I'd risk it in Linux. I have no data to support thinking this way; it's just worth trying.

If you're running a recent version of Linux, it looks as though the scariness in the link I posted as the man page might be too hasty. Here's the scoop on the man page as distributed with Debian lenny. If nothing on that man page gives you specific pause, I'd say use it if you want.

Code:

NOTES
       The  alloca() function is machine- and compiler-dependent.  For certain
       applications, its use can improve efficiency compared  to  the  use  of
       malloc(3)  plus free(3).  In certain cases, it can also simplify memory
       deallocation in applications  that  use  longjmp(3)  or  siglongjmp(3).
       Otherwise, its use is discouraged.

       Because  the  space allocated by alloca() is allocated within the stack
       frame, that space is automatically freed  if  the  function  return  is
       jumped over by a call to longjmp(3) or siglongjmp(3).

       Do not attempt to free(3) space allocated by alloca()!

   Notes on the GNU Version
       Normally,  gcc(1) translates calls to alloca() with inlined code.  This
       is  not  done  when  either  the  -ansi,  -std=c89,  -std=c99,  or  the
       -fno-builtin  option  is  given  (and  the  header  <alloca.h>  is  not
       included).  But beware!  By default the  glibc  version  of  <stdlib.h>
       includes <alloca.h> and that contains the line:

           #define alloca(size)   __builtin_alloca (size)

       with  messy consequences if one has a private version of this function.

       The fact that the code is inlined means that it is impossible  to  take
       the address of this function, or to change its behavior by linking with
       a different library.

       The inlined code often consists of a single instruction  adjusting  the
       stack  pointer,  and does not check for stack overflow.  Thus, there is
       no NULL error return.

BUGS
       There is no error indication if the stack  frame  cannot  be  extended.
       (However, after a failed allocation, the program is likely to receive a
       SIGSEGV signal if it attempts to access the unallocated space.)

       On many systems alloca() cannot be used inside the list of arguments of
       a  function  call,  because  the stack space reserved by alloca() would
       appear on the stack in the middle of the space for the  function  argu-
       ments.