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.
Related
Is there any way how to find out where the person forgot to free() memory?
Valgrind only says how many allocs and frees there were but not where the person didnt free when he should have. Is there any way how to find out the piece of memory that should be freed?
I guess that what you would like is to have valgrind reporting an error
when you 'lose' the last pointer to a piece of memory.
valgrind does not have such a functionality. There used to be an experimental
tool doing that (--tool=omega), but it is not (anymore?) in the valgrind
repository, IIUC, because there was many false positive and/or false negative.
The closest you can do is to use valgrind + gdb (via vgdb), and put
some breakpoints at various places in your program, and do a leak search
at all these places. With a kind of 'dichotomic' search, you might find
the place where you lose the pointer.
See http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
and http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
for more details about using gdb with valgrind and doing interactive
leak searches.
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
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.
what is the most efficient and accurate way/ API to measure heap memory consumption from the same running process programmatically? I want to estimate (as accurately as is reasonably possible) how much memory has been new or malloc since startup, minus the memory that has been free or delete
the scope of the question is linux and possibly other linux environments. The language is either C or C++
EDIT
It is enough for my purposes to know the actual number (and size) of allocated/held blocks by any malloc implementation, i don't need the detail of actual malloc memory minus the the freed memory
Assuming new uses malloc look here.
For more details of a processes memory allocation, look at the /proc/[pid]/maps.
Also note that linux implements copy-on-write. This means that sometimes processes can share memory. This is especially true if the process was forked without calling exec afterwards.
You can use mallinfo for an estimation. I've just found this, not sure whether this is process or system.. :/
I'm not totally sure what you are asking, malloc minus freed is less than the actual usage because of the memory fragmentation, if you really need that number you have to use custom allocators (which are tiny wrappers around existing ones) everywhere in your code which is going to be painful.
Have you considered reading from /proc/u/stat? (where "u" is your pid)
If you use valgrind and run your program to completion, it gives you a report on memory usage.
http://valgrind.org/
You can get quite a bit of information about your heap usage by linking against tcmalloc from Google Perftools. It is designed to locate memory leaks and determine "who the heck allocated all that RAM", but it provides enough instrumentation to answer most questions you might have about your heap.
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.