I am doing some tests with Libgcrypt and when I use valgrind to check the memory usage there is 3,200 bytes in use at exit.
I have tried to use
valgrind --leak-check=full --track-origins=yes --show-reachable=yes ./my_program
But valgrind valgrind only complains about this line from my code:
version = gcry_check_version("1.5.0");
and valgrind about internal functions of Libgcrypt.
My test code is here: http://www.tiago.eti.br/storage/post2.c
And I am using Libgcrypt 1.5.0 from Debian sid repository
It is a bug of Libgcrypt or am I doing anything wrong?
Not all libraries are perfectly careful to clean up all their resources. As long as some "permanent" allocations happen only once and are in use until the end of the program (for example for a version string), it is entirely possible that the library just never bothers to deallocate this.
Thus is the unfortunate reality of dealing with third-party libraries, and if it bothers you, you should make a suppression file for Valgrind with --gen-suppressions=all.
Bear in mind that "still reachable" memory is just "laziness", and not really a leak, since you never actually lost the allocation. A leak should be considered a true programming error, while still reachable, un-deallocated memory may or may not be a forgivable shortcut.
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.
for example
==26460== 2 bytes in 1 blocks are still reachable in loss record 2 of 105
==26460== at 0x4C28BE3: malloc (vg_replace_malloc.c:299)
==26460== by 0x580D889: strdup (in /usr/lib64/libc-2.17.so)
==26460== by 0x4F50AF: init (init.c:468)
==26460== by 0x406D75: main (main.c:825)
I want to not check init.c:468: mode = strdup, i'm sure this only malloc once, and will last whole process life.
Is it possible to make valgrind not check this line?
As I said in my comment: I recommend not to.
But Valgrind does have a feature to suppress warnings.
The most convenient way of suppressing a specific message is supported by the feature dedicated to exactly that purpose:
--gen-suppressions=yes
Which apparently will ouptput the precise suppression syntax for each/any generated message.
See 5.1 in the FAQ:
http://valgrind.org/docs/manual/faq.html#faq.writesupp
(I love their style:
"F:Can you write ... for me?" and I expected a totally adequate
"A:No." But they actually answer
"A: Yes ...". Beyond cool.)
You should fix the leaks; it is far better to do so.
You can't stop Valgrind checking for the leaks, but you can stop it reporting them by suppressing the leaks.
Use:
valgrind --gen-suppressions=yes --leak-check=all -- tested-program …
You can then save the suppressions in a file, say tp.suppressions, and subsequently you use:
valgrind --suppressions=tp.suppressions -- tested-program …
If you work on a Mac like I do, and work with bleeding edge systems, you'll often find it necessary to suppress leaks from the system startup code — memory that's allocated before main() is called and which you cannot therefore control.
OTOH, it is routine that after the new release of macOS, it takes a while to get Valgrind running again. I upgraded to macOS High Sierra 10.13; Valgrind has stopped working again because the kernel isn't recognized.
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.
Valgrind reports multiple memory leaks in my program, some of which are recurring leaks (i.e. they occur in multiple blocks), but most of which are one-timers, i.e. allocations that happen at program initialization and that I don't care to take care of before the program exits. I know I can write suppression files to suppress leaks from specific libraries, functions etc., but I haven't found a way to suppress leaks a limited number of times. Is there a way of doing this?
Currently, I use a small program I wrote to filter Valgrind's report file from one-time leaks (so when a paragraph in the report file starts with X bytes leaked in 1 blocks, that paragraph is removed from the report file), but obviously I'd prefer to configure Valgrind to suppress these leaks instead, not least because my filter does nothing to keep the leak summary accurate.
I'm asking because the leaky initialization code is generated by a compiler that compiles to C from the language in which I'm writing my program and that I have little interest in modifying.
Valgrind does not report errors for allocated memory that is still accessible at program exit, so you have bona fide leaks, even if the amount of memory leaked is fixed and (for the moment) inconsequential. Consider actually freeing your pointers, or else ensuring that they do not go out of scope or get overwritten. Under some circumstances you could use arrays instead of dynamically-allocated memory.
If you insist on using suppressions to silence reporting on genuine leaks, however, then make Valgrind do the work for you. Add the option --gen-suppressions=yes (if you want to interactively select which suppressions to generate) or --gen-suppressions=all (to generate suppressions for all errors) to your valgrind command line. You'll need to copy the suppression descriptors Valgrind outputs into your suppression file.
I'm developing a library using a number of glib datastructures (GHashTable, GSList etc.). I've been checking my code frequently for memory leaks using valgrind. Most of the issues valgrind points out are quite easy to fix, however there's a few that I can't figure out.
All of these are reported as 'possibly lost'.
At the top of the valgrind stacktrace, I always find the same 4 libraries:
==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997== at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997== by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997== by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997== by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)
Further down in the call stack, there is always a call to a glib function, such as g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().
My questions are:
Has anyone come across this and found a way around it?
Or is this something I can disregard? Is it due to glib using memory pools, as suggested here?
I am using
valgrind-3.5.0
glib-2.12.3
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
CentOS release 5.5 (Final)
GLib has a few features that confuse Valgrind.
One is memory pools (g_slice in newer glib, "mem chunks" in older). These are specialized allocators used for small objects such as list nodes. You can use this to disable the slice allocator:
G_SLICE=always-malloc valgrind myprogram
A second issue is that sometimes GLib would avoid initializing new memory or keep dead pointers in freed slices/chunks. You can fix this with:
G_DEBUG=gc-friendly valgrind myprogram
So together of course:
G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram
A third issue is that GLib has global variables that are simply never freed but considered permanent program state. For example registered GType are never unloaded, and a few others. This is not fixable, but valgrind should show these global allocations as reachable, rather than as lost.
glib-2.12 is quite old.
Try getting glib-2.24, compile and install it (with --prefix=/usr/local/glib-2.24 for example) then use it to compile your application.
If you still have this, try to read the glib manual again :)