Memory leaks

Summary:

Two memory leaks found in the library

Memory leaks

Manuel Jouglet Marcus (guest) 25 Jan 2011 11:29

Hello,

I compile your very good library under VS2010. I successfully removes the GTK+ dependencies (because I don't use it and this is a big library to add just for performing malloc and free…).

Using it, I found two memory leaks when I used it (through Image Magick implementation).

I add the following lines:

void lqr_rwindow_destroy(LqrReadingWindow *rwindow)
{

…
…

g_free(buffer[0]);
g_free(buffer);
g_free(rwindow); // Added!
}

And the second leak:

void lqr_carver_destroy(LqrCarver *r)
{
if (!r->preserve_in_buffer) {
g_free(r->rgb);
}
if (r->root == NULL) {
g_free(r->vs);
}
g_free(r->rgb_ro_buffer); // added
g_free(r->en);
…
}

Thanks you a lot for your implementation,
Manuel Jouglet Marcus

Re: Memory leaks

CarloB 25 Jan 2011 13:55

Thanks a lot! I have pushed the fixes you proposed to the git repository and they'll be included in the next release.

About the use of glib: it is true that it is a big library, but please note that:

1. it should ensure that the variable types are the same whatever the platform you compile the library on
2. it is not only used for alloc and free, but also for performing atomic operations (this is relevant if you need the "cancel" functionality)
3. in the (far?) future I could rely on it more heavily, e.g. switching to the use of GObjects (internally)

Of course, everyone is free to determine how relevant this is for his own needs.

(Just in case anybody should need it, I'll leave this here: glib binary packages and headers for Windows can be downloaded from this page.)

Manuel Jouglet Marcus (guest) 28 Jan 2011 08:43

Thanks for correcting the leaks.

Concerning glib, I took the types declaration from the glib headers.
I also took the operations relative to atomic operations from the headers.

From my point of view, that would be great to limit your glib dependencies, because the more you add external dependencies to your library, the less it will be portable.

I write a software which is call 3D Photo Browser (in which liblqr will be included) and 3D Photo Browser already requires many libraries.
In my case it was very important to remove the glib dependencies because it would have increase significantly the size of the executable.
It also remove the time needed to find the correct glib package, makes it compile, follows the code, makes it work on different platform…
So I prefer to remove dependencies each time it's possible.

Anyway, many thanks for your work.
If you are interested by the win32 header I wrote for portability, It will be a pleasure to sent it to you.
Let me also know if you are also interested by a license of 3D Photo Browser.

Manuel Jouglet Marcus