Actually, I know it's necessary to free the memory allocated with malloc(), but I wonder if I can know there is some memory left being not collected if I forget to collect it with free().
Valgrind would be your best bet
http://valgrind.org/
In addition to valgrind answers, you may link your executables against Boehm GC – C garbage collector that may run in leak detection mode.
https://en.wikipedia.org/wiki/Boehm_garbage_collector
http://www.hboehm.info/gc/
http://www.hboehm.info/gc/leak.html
You can use a tool like valgrind. Check out this video on how to use it, courtesy of Harvard's CS50 available on edx. It gives a very good explanation on how to use it, as well as some examples on both correct and incorrect code.
What you are trying to do is impossible. Just keep track of all the memory you allocated and erase it when needed
Related
When using LibreSSL's libtls, is it possible to free the memory that is allocated by tls_init()?
I found using valgrind that a simple program that only calls tls_init() code leaves 2058 blocks of memory "still reachable". I am aware that "still reachable" memory is not strictly a memory leak and it will be cleaned up by the OS when the program exits... But it makes identifying my own memory issues much more obnoxious.
OpenSSL's SSL_library_init() doesn't seem to have the same problem.
I'm on Linux with a source build from the libressl-portable github page.
This question was also asked on the libressl mailing list. The answer is no, at least not with the current libtls API.
The current best alternative for memory testing with valgrind is to use the --suppressions option.
Is there an easy way to know the total amount of memory that has been allocated by every malloc in the program?
I'm suffering from a memory leak and I want to find out where it is.
There is no way in a standard, operating system neutral, fashion.
But with GNU Glibc you have mallinfo
On Linux systems, you can learn about your virtual memory map thru the /proc/self/maps (or /proc/self/smaps which gives more details) pseudo-file. For process of pid 123 you can read /proc/123/maps
Of course, details are system specific.
To find a memory leak, use a tool like valgrind
By a specific malloc, yes, you have as much memory as you asked for and no more :-)
In reality, it may give you a little more (many implementations will give you a multiple of 16 or 32 bytes) but there's no way to tell in standard C how much. Using more than you asked for is undefined behaviour, no matter what sort of padding goes on.
Some systems have a mallinfo function which you can call to get statistics on the overall memory arena, if you want to know how much memory in total has been allocated. You could look into that but, again, it's not standard.
There's no standard method to do so. Microsoft's C library has a _heapwalk function that you could use to compute it.
You allocated the memory in the first place, just make a note of how much. Perhaps use a struct to store both the pointer and the size.
Use valgrind to help in debugging a potential memory leak.
In you want to do some C debugging, glibc has some functions to help you in debugging with malloc.
Hooks for malloc
http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html
Heap Consistency Checking
http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html
Statistics for Memory Allocation with malloc
http://www.gnu.org/software/libc/manual/html_node/Statistics-of-Malloc.html
I have a question out of curiosity relating to checking for memory leaks.
Being someone who has used valgrind frequently to check for memory leaks in my code for the last year or two, I suddenly came to think that it only detects lost/unfreed memory after the life of the program.
So, in light of that, I was thinking that if you have a long-running program which malloc()'s intermittently and doesn't free() until the application exits, then the potential to eat memory (not necessarily through leaks) is huge and isn't observable using these tools because they only check after the programs lifetime. Are there GDB-like tools which can stop an application while running and check for memory which is and isn't referenced at an instance in the life of the application?
Are there GDB-like tools which can stop an application while running and check for memory which is and isn't referenced at an instance in the life of the application?
Yes: Valgrind.
Specifically, the SVN version of Valgrind has a gdbserver stub embedded into it.
This allows you to do all kinds of cool debugging, not possible before:
You can run program under valgrind and have GDB breakpoints at the same time
You can ask valgrind: is this memory allocated? was this variable initialized?
You can ask valgrind: what new leaks happened since last time I asked for leaks?
I think you can also ask it to list not-leaked new allocations.
What I have done, which was not a tool, for a long-running socket-based server, was to do an operation, but before that print out the amount of free memory, then print it out after my operation, and see if there was any difference.
I knew that in theory my server should have returned all memory used on each call to the server, so if I was the only one calling it, it shouldn't use much more memory than when it started.
You may find that some memory was needed on the first call, so you may want to make several calls, so everything is initialized, then you can do checks like this.
The other option is to create a list of all memory you are mallocing, then when you free it delete from the list that node, and at the end, see which ones still haven't been freed.
That is not generally possible in a language that supports pointer arithmetic, since for example - you could cast an pointer to an integer and back. See http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html
Leaked memory is defined as memory that is not referenced by anything in the program.
If you malloced memory and somewhere in your data there is a pointer pointing to that memory it isn't "lost" as far as any automatic check can now.
However, if you allocated memory, never free'ed it but you don't have any pointer pointing to it you have most likely leaked that memory - as there is no way for you to reference it.
Programs like valgrind can find leaks of the kind described above (lost of reference). AFAIK nothing can find "logical" leaks where you still hold a reference to the memory.
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.
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.