What happen if I end the execution by passing return 0; after using a malloc and without freeing the part of memory allocated?
int * var;
var = (int *)malloc(sizeof(int)) ;
free(var) ;
return 0;
The program contains a memory leak, as explained here. To answer the question specifically, the effect of the memory leak depends on the environment; in the best case, nothing happens, in the worst case, the machine might crash sooner or later. The existence of the memory leak is to be regarded as a bug in any case.
It is implementation specific.
On most operating systems (notably desktop or server OSes, e.g. Linux, MacOSX, Windows...) once a process is terminated, every used resources is released, and that includes its virtual address space. Hence even unfreed heap memory is released.
In particular, if you code a quickly running program (e.g. you know that it always will run in less than few seconds), it might be easier to accept some memory leak (but if you do, please comment that in your code and/or documentation). And many real life programs are doing that (in particular the GCC compiler, and probably several Unix shells).
On the contrary, if you are coding a server (e.g. a database or compute server), you should avoid any memory leaks which would make the server's process RSS grow indefinitely (till some crash). You usually should take great care that every allocated heap memory to deal with one request gets free-d after replying to that request.
On some embedded operating systems, if you don't release all the resources explicitly (free all heap allocated memory, fclose all opened streams) and properly, you have a resource leak.
See also this related question. On many OSes (including Linux) you can use valgrind to hunt memory leak bugs. With a recent gcc you might use debugging options like -g -fsanitize=address
Read also (at least for the concepts and the terminology) something about garbage collection and about fragmentation. If programming in C, you might consider using Boehm's garbage collector.
There is however a very good practical reason to systematically free all previously malloc-ed memory: it is a good programming discipline, and it helps a lot using tools like valgrind which helps debugging genuine memory bugs. Also it makes your code more clean, and you could reuse it in some different contexts (e.g. as part of some library, usable in long-running processes).
If you don't free the memory, your application will have a memory leak. So if you don't free the memory and leave the application on for a couple of days, it will start to slow down, and eventually crash.
Related
This question already has answers here:
What REALLY happens when you don't free after malloc before program termination?
(20 answers)
When you exit a C application, is the malloc-ed memory automatically freed?
(9 answers)
Closed 9 years ago.
int main()
{
char *a = malloc(1024);
return 0;
}
Does the program above have a memory leak? Please provide as complete and technical answer as it is possible.
The program itself has a leak. Whether the operating system cleans this up or not is a different matter. I suppose it's better to ask 'could this program potentially cause a problem on any system?' and the answer is absolutely yes.
The C standard nowhere says that memory allocated with malloc will be freed at program termination, either normal or abnormal. Compare that to open files, which are guaranteed to be closed for you by the C implementation if the program terminates normally.
Simple answer is yes. The OS is doing the tidying up for you
EDIT
For the benefit of gg.kaspersky.
When the program gets to the end you should have tidied up the heap. It says that you have considered all the allocations and provided the release of those resources (this can be said to be true for open files or other OS resources).
Is this complicated enough for you?
BTW - It is good manners when visiting a home (OS) you leave it in the same state as you arrived.
Your question is incomplete... and as such the best answer you can get is "it depends".
From a program scope, yes, you have a memory leak. That much should be obvious. From a system scope the answer is it depends on which operating system you're running on.
In general if you're programming on a main stream device (Win7/MacOSX/Linux desktop/laptop computer, iOS/Android device, etc) you're pretty safe. I can't think of any main stream modern operating systems which would not be able to clean up after you.
However, if you're working on some older or embedded systems, you will leak memory here. I've seen memory leaks on a uCLinux platform (an OS specifically designed for hardware which does not have an MMU[Memory Management Unit]).
Dynamic memory is generally considered dangerous, which is why it's not legal to use it on some RTOSs. If you know the scope of deployment of your application throughout the lifetime of its use, you're fine to code like this... but the odds are you don't, and you shouldn't make assumptions about what the OS will do. Always clean up your own mess.
I wouldn't consider that a memory leak. The memory is still accessible through a variable that is still in scope when you exit.
Freeing all memory you allocated at the end of a program is just being unnecessarily pedantic and makes you spend time doing something that the operating system will do for you much more efficiently.
Edit (technical details):
With some implementations of malloc doing unnecessary freeing of memory at the end of a program can be horribly inefficient. All malloc implementations that keep their accounting information inline (through boundary tags or a similar mechanism) will touch most, if not all, pages that you have allocated. Normally this isn't a problem besides dirtying cache lines and TLB entries that are being thrown away, but couple this with a program that used enough memory to start using swap and you end up swapping in a lot of memory just to free it. The operating system can do this much more efficiently when you exit (by just marking the swap slots as free).
If you have a malloc implementation that returns memory to the operating system, freeing the memory will cause the operating system to unmap the memory which in turn requires expensive TLB operations if you're on a multiprocessor system. On exit the invalidation can be done much more efficiently (either by doing a full TLB flush or invalidating the TLB tag).
The OS will just recover it (after the program exits) right? So what's the use other than good programming style? Or is there something I'm misunderstanding? What makes it different from "automatic" allocation since both can be changed during run time, and both end after program execution?
When your application is working with vast amounts of data, you must free in order to conserve heap space. If you don't, several bad things can happen:
the OS will stop allocating memory for you (crashing)
the OS will start swapping your data to disk (thrashing)
other applications will have less space to put their data
The fact that the OS collects all the space you allocate when the application exits does not mean you should rely upon this to write a solid application. This would be like trying to rely on the compiler to optimize poor programming. Memory management is crucial for good performance, scalability, and reliability.
As others have mentioned, malloc allocates space in the heap, while auto variables are created on the stack. There are uses for both, but they are indeed very different. Heap space must be allocated and managed by the OS and can store data dynamically and of different sizes.
If you call a macro for thousand times without using free() then compiler or safe to say system will assign you thousand different address, but if you use free() after each malloc then only one memory address will be given to you every time.
So chances of memory leak, bus error, memory out of bound and crash would be minimum.
Its safe to use free().
In C/C++ "auto" variables are allocated on the stack. They are destroyed right at the exit from the function. This will happen automatically. You do not need to write anything for this.
Heap allocations (result of a call to malloc) are either released explicitly (with a call to free) or they are cleaned up when the process ends.
If you are writing small program that will be used maybe once or twice, then it is ok not to free your heap allocations. This is not nice but acceptable.
If you are writing medium or big project or are planning to include your code into other project, you should definitely release every heap allocation. Not doing this will create HUGE trouble. The heap memory is not endless. Program may use it all. Even if you will allocate small amount of memory, this will still create unnedded pressure on the OS, cause swapping, etc.
The bottom line: freeing allocations is much more than just a style or a good habit.
An automatic variable is destroyed (and its memory is re-usable) as soon as you exit the scope in which it is defined. For most variables that's much earlier than program exit.
If you malloc and don't free, then the memory isn't re-usable until the program exits. Not even then, on some systems with very minimal OS.
So yes, there's big difference between an automatic variable and a leaked memory allocation. Call a function that leaks an allocation enough times, and you'll run out of memory. Call a function with an automatic variable in it as many times as you like, the memory is re-usable.
It is good programming style and it's more than that. Not doing proper memory management in non-trivial programs will eventually influence the usability of your program. Sure the OS can reclaim any resources that you've allocated/used after your program terminates, but that doesn't alleviate the burden or potential issues during program execution.
Consider the web browser that you've used to post this question: if the browser is written in a language that requires memory management, and the code didn't do it properly, how long do you think it would be before you'd notice that it's eating up all your memory? How long do you think the browser would remain usable? Now consider that users often leave browsers open for long periods of time: without proper memory management, they would become unusable after few page loads.
If your program does not exit immediately and you're not freeing your memory you're going to end up wasting it. Either you'll run out of memory eventually, or you'll start swapping to disk (which is slow, and also not unlimited).
automatic variable is on the stack and its size should be known on compilation time. if you need to store data that you don't the size, for example, maintain a binary tree, where the user add and removes objects. beside that stack size might be limited (depends on your target), for example, linux kernel the stack is 4k-8k usually. you also trash the instruction cache, which affects performance,
Yes you absolutely have to use free() after malloc() (as well as closing files and other resources when you're done). While it's true that the OS will recover it after execution, a long running process will leak memory that way. If your program is as simple as a main method that runs a single method then exists, it's probably not a big deal, albeit incredibly sloppy. You should get in the habit of managing memory properly in C because one day you may want to write a nontrivial program that runs for more than a second, and if you don't learn how to do it in advance, you'll have a huge headache dealing with memory leaks.
I have to do a project in C where I have to constantly allocate memory for big data structures and then free it. Does there exista a library with a function that helps to keep track of the memory usage so I can be sure if I am doing things correctly? (I'm new to C)
For example, a function that returns:
A) The total of memory used by the program at the moment, OR
B) The total of memory left,
would do the job. I already googled for that and searched in other answers.
Thanks!
Try tcmalloc: you are looking for a heap profiler, although valgrind might be more useful initially.
If you're worried about memory leaks, valgrind is probably what you need. On the other hand, if you're more concerned just with whether you're data structures are using excessive memory, you might just use the common mallinfo function included as an extension to malloc in many unix standard libraries including glibc on Linux.
Although some people excoriate it, the book "Writing Solid Code" by Steve Maguire has a lot of reasonable ideas about how to track your memory usage without modifying the system memory allocation functions. Basically, instead of calling the raw malloc() etc functions directly, you call your own memory allocation API built on top of the standard one. Your API can track allocations and frees, detect double frees, frees of non-allocated memory, unreleased (leaked) memory, complete dumps of what is allocated, etc. You either need to crib the code from the book or write your own equivalent code. One interesting problem is providing a stack trace for each allocation; there isn't a standard way to determine the call stack. (The book is a bit dated now; it was written just a few years after the C89 standard was published and does not exploit const qualifiers.)
Some will argue that these services can be provided by the system malloc(); indeed, they can, and these days often are. You should look carefully at the manual provided for your version of malloc(), and decide whether it provides enough for you. If not, then the wrapper API mechanism is reasonable. Note that using your own API means you track what you explicitly allocate, while leaving library functions not written to use your API using the system services - as, indeed, does your code, under the covers.
You should also look into valgrind. It does a superb job tracking memory abuses, and in particular will report leaked memory (memory that was allocated but not freed). It also spots when you read or write outside the bounds of an allocated space, spotting buffer overflows.
Nevertheless, ultimately, you need to be disciplined in the way you write your code, ensuring that every time you allocate memory, you know when it will be released.
Every time you allocate/free memory, you could log how big your data structure is.
Are there any "good" C libraries for garbage collection?
I know about the Boehm GC, is it maintained nowadays?
What about http://tinygc.sourceforge.net?
What are your experiences with these libraries?
You could use Boehm's Garbage Collector. Many projects I have worked with use it.
Although I do not know of a good, easy, and effective GC for C, I would like to weigh in some thoughts.
For many years, I avoided heap allocations for fear of memory leaks. And I do not know of any way to have a memory leak without allocating from the heap.
But I do not know of any better way to return memory from a function (such as a string, or an array of structs) than by heap allocation. Heap allocation allows you to allocate precisely the amount of memory you need without knowing how much memory you need at compile time. If your program will load files to memory, you probably will not know at compile time how much memory you might need. If you go the static memory route, then you always have to allocate the maximum memory you might ever need. Then your program can become a memory hog when it does not need to be. Heap is better.
But then keeping track of heap allocations can be difficult in some kinds of programs, for example, a program that has many modules inserting and deleting elements from an in-memory database. And memory leaks can be so difficult to solve. A good GC seems to me a very good way to stop memory leaks because of the automated tracking and freeing of heap allocations.
So, this post responds to the comment that "If you have problems in C using malloc() and free() correctly, you should switch to another language." If the programming problem is complicated and the solution needs heap allocations, the even the best programmers will have to debug memory leaks.
In some programs, there could be an alternative to using garbage collection: You can assume that an operating system will free all the program's allocations when the program terminates. So, your main program might be able to call a second program that uses heap allocations then writes results to a file and terminates. I tested this on Windows. I observed that Windows deallocated heap memory that my test program allocated on the test program's termination. I ran the test program many times. There was no diminishing of available memory.
Of course, having a second program that runs a short while and terminates is often not a viable solution.
What are some techniques in detecting/debugging memory leak if you don't have trace tools?
Intercept all functions that allocate and deallocate memory (depending on the platform, the list may look like: malloc, calloc, realloc, strdup, getcwd, free), and in addition to performing what these functions originally do, save information about the calls somewhere, in a dynamically growing global array probably, protected by synchronization primitives for multithreaded programs.
This information may include function name, amount of memory requested, address of the successfully allocated block, stack trace that lets you figure out what the caller was, and so on. In free(), remove corresponding element from the array (if there are none, a wrong pointer is passed to free which is also a error that's good to be detected early). When the program ends, dump the remaining elements of the array - they will be the blocks that leaked. Don't forget about global objects that allocate and deallocate resources before and after main(), respectively. To properly count those resources, you will need to dump the remaining resources after the last global object gets destroyed, so a small hack of your compiler runtime may be necessary
Check out your loops
Look at where you are allocating variables - do you ever de-allocate them?
Try and reproduce the leak with a small subset of suspected code.
MAKE trace tools - you can always log to a file.
One possibility could be to compile the code and execute it on a system where you can take advantage of built in tools (e.g. libumem on Solaris, or the libc capability on Linux)
Divide and conquer is the best approach. If you have written you code in a systematic way, it should be pretty easy to call subsets of you code. Your best bet is to execute each section of code over and over and see if your memory usage steadily climbs, if not move on to the next section of code.
Also, the wikipedia article on memory leaks has several great links in the references section on detecting memory leaks for different systems (window, macos, linux, etc)
Similar questions on SO:
Memory leak detectors for C
Strategies For Tracking Down Memory Leaks When You’ve Done Everything Wrong
In addition to the manual inspection techniques mentioned by others, you should consider a code analysis tool such as valgrind.
Introduction from their site:
Valgrind is an award-winning
instrumentation framework for building
dynamic analysis tools. There are
Valgrind tools that can automatically
detect many memory management and
threading bugs, and profile your
programs in detail. You can also use
Valgrind to build new tools.
The Valgrind distribution currently
includes six production-quality tools:
a memory error detector, two thread
error detectors, a cache and
branch-prediction profiler, a
call-graph generating cache profiler,
and a heap profiler. It also includes
two experimental tools: a
heap/stack/global array overrun
detector, and a SimPoint basic block
vector generator. It runs on the
following platforms: X86/Linux,
AMD64/Linux, PPC32/Linux, PPC64/Linux,
and X86/Darwin (Mac OS X).
I have used memtrace
http://www.fpx.de/fp/Software/MemTrace/
http://sourceforge.net/projects/memtrace/
You may need to call the statistics function to printout if there are any leaks. Best thing is to call this statistics function before and after a module or piece of code gets executed.
* Warning * Memtrace is kind enough to allow memory overwrite/double free. It detects these anomalies and gracefully avoids any crash.