Re: [gmime-devel] Memory leaks while compiling a test gmime c code

[stedfast comcast net]

Hi Ashay, 

The memory leaks you found aren't actually memory leaks (they are still reachable which means that
there are pointers pointing to those memory blocks). What you are seeing is memory allocated in the
initialization of the GLib library and when registering types with GLib's GObject type system. Since
GLib does not have a "shutdown" method, it is impossible for GMime to free those resources.

All of those "leaks" can safely be ignored because they will be cleaned up by the kernel when your
program exits.



>From http://es.gnu.org/~aleksander/valgrind/valgrind-memcheck.pdf:

1.4.1 Still reachable blocks

A block of memory is reported to be Still Reachable when Memcheck finds, after process
execution ends, at least one pointer with the start address of the block (a start-pointer).
This pointer found can be either in stack (a global pointer, or a pointer in the main function),
or in heap if it was referenced by another start-pointer (which again could be in the stack, or
referenced by another start-pointer, thus forming a chain of start-pointers).

Usually, ’Still Reachable’ memory leaks are not considered harmful in the standard development.
There are stable and popular libraries in the Free Software world (talking about GLib and GTK+
here) which dynamically allocate a lot of heap memory for data which should be available during
the whole execution of the program; this is, memory which shouldn’t be deallocated until program
is about to exit. And in this situation, instead of explicitly freeing this memory before the return
of the main function, it’s just easier and faster to leave the kernel do it automatically when the
process ends.



Hope that helps,

Jeff