Memory leak

[Alexandr Grigorcea]

I've already reported this here https://bugs.launchpad.net/gloobus-preview/+bug/505644/comments/3 for pdf files , but now I noticed that it happens with any kind of files
opened a folder with 2 images, after 20-30 switches got 24% of memory usage of my 4Gb
some files eat less memory, other more
rev173

[BadChoice (guitarboy000)]

I see... everytime I change a file, it doesn't free the any memory.. really strange cause I have the g_free for each pixbuf and things, but sure there is a lack somewhere if anybody can help in finding it... I would be very greatefull ;)

[Alexandr Grigorcea (cahr-gr)]

I'm do not know much about gtk, but I've been looking through the code and have an idea:
you have a get_pixbuf() method that loads the file and returns a pointer with ref. counter at 1, after that you are scaling it and creating m_pixbufFull and m_pixbuf ( rescaling twice in a row not very good :P )
but after that what happens with the first pixbuf? you call
g_object_unref (m_pixbuf);
g_object_unref (m_pixbufFull);
but nothing for the first one, I pushed a small fix, after 20 switched on 2 small images, used memory dropped from 6.5% to 4%, so there is something else, I'll keep looking

----------------------------
now, as I understand, iText does not have any destroy method and end() does nothing
iPdf and iDocument destroy methods do nothing
will look other plugins later

[BadChoice (guitarboy000)]

It seems that I lose mem in the scale_pixbuf function..
And in other sites, I use valgrind to check this but I couldn't find the source..

iPdf has a destroy method that unrefs all pages, I think is called

In gloobus-preview-singleton line 128 there is the destroy plugin function called everytime you change file or you quit gloobus-preview.
It calls the end function and the destructors as it destroys the plugin.

the iDocument::destroy does nothing cause its done by the iPdf plugin, if you run with --debug i think you'll see the destroyng page messages..

but sure there are more memleaks

I'll merge with your patch and try to track more of them today

Thanks!

[Alexandr Grigorcea (cahr-gr)]

ok. I've found where iPdf pages are destroyed, but what happens with
temporary pixbufs? they are still there, shouldn't you unref them?
from library.gnome:
Creates a new GtkImage<http://library.gnome.org/devel/gtk/unstable/GtkImage.html>displaying
*pixbuf*. The GtkImage<http://library.gnome.org/devel/gtk/unstable/GtkImage.html>does
not assume a reference to the pixbuf; you still need to unref it if
you
own references.
GtkImage<http://library.gnome.org/devel/gtk/unstable/GtkImage.html>will
add its own reference rather than adopting yours.

and, as I unterstand, you should call g_object_unref(m_document); in
~iPdf(). otherwise m_document remains in memory

On Wed, Feb 17, 2010 at 2:42 PM, Jordi Puigdellívol <email address hidden>wrote:

> It seems that I lose mem in the scale_pixbuf function..
> And in other sites, I use valgrind to check this but I couldn't find the
> source..
>
> iPdf has a destroy method that unrefs all pages, I think is called
>
> In gloobus-preview-singleton line 128 there is the destroy plugin function
> called everytime you change file or you quit gloobus-preview.
> It calls the end function and the destructors as it destroys the plugin.
>
> the iDocument::destroy does nothing cause its done by the iPdf plugin,
> if you run with --debug i think you'll see the destroyng page messages..
>
> but sure there are more memleaks
>
> I'll merge with your patch and try to track more of them today
>
> Thanks!
>
> --
> Memory leak
> https://bugs.launchpad.net/bugs/522384
> You received this bug notification because you are a member of Gloobus
> Developers, which is the registrant for gloobus-preview.
>
> Status in Gloobus Preview: Confirmed
>
> Bug description:
> I've already reported this here
> https://bugs.launchpad.net/gloobus-preview/+bug/505644/comments/3 for pdf
> files , but now I noticed that it happens with any kind of files
> opened a folder with 2 images, after 20-30 switches got 24% of memory usage
> of my 4Gb
> some files eat less memory, other more
> rev173
>
>
>

[BadChoice (guitarboy000)]

ummmm

I don't understand those references so much but, when I destroy the widget (wich contains the gtkImages) it destroys the gtkImages right? then it decrases the reference count, finally when I unref the pixbuf in ~iPdf() ref count should be 0?

But sure I'm wrong cause there are the mem leaks

[Alexandr Grigorcea (cahr-gr)]

iPdf creates pixbufs of pages (ref count 1), iDocument uses them to create
gtkImages (image adds reference, so ref count 2) ... iDocument->end()
destroys gtkImages (ref count again 1) and ~iPdf does nothing (it prints a
message), it just can't, because those pointers are lost, at some point you
need to unref pixbufs
just checked that, on 2 small pdfs after 5 switches mem usage was 14%, now
it 3-4%, but it still leaks, after 50 switches memory usage increments of
0.5%

On Wed, Feb 17, 2010 at 5:34 PM, Jordi Puigdellívol <email address hidden>wrote:

> ummmm
>
> I don't understand those references so much but, when I destroy the
> widget (wich contains the gtkImages) it destroys the gtkImages right?
> then it decrases the reference count, finally when I unref the pixbuf in
> ~iPdf() ref count should be 0?
>
> But sure I'm wrong cause there are the mem leaks
>
> --
> Memory leak
> https://bugs.launchpad.net/bugs/522384
> You received this bug notification because you are a member of Gloobus
> Developers, which is the registrant for gloobus-preview.
>
> Status in Gloobus Preview: Confirmed
>
> Bug description:
> I've already reported this here
> https://bugs.launchpad.net/gloobus-preview/+bug/505644/comments/3 for pdf
> files , but now I noticed that it happens with any kind of files
> opened a folder with 2 images, after 20-30 switches got 24% of memory usage
> of my 4Gb
> some files eat less memory, other more
> rev173
>
>
>

[BadChoice (guitarboy000)]

I've just tried that and I get a double free error XDD

I created a pixbuf* list so I can delete them and then I get that error...
I'm gona check it deeper and see what I find

[BadChoice (guitarboy000)]

Woopss I were doing it wrong, now it works ;)

[ammonkey (am-monkeyd)]

still big memory leeks when u're browsing images with gloobus-preview it eat all the ram of you computer until freeze crash of the system. Nothing is freed from a preview to another. This render gloobus-preview barely usable.

[Alexandr Grigorcea (cahr-gr)]

hm, it was a little bit better before, now there is some new pixbuf
animation stuff that is never freed, so it leaks great on images

On Sat, Aug 21, 2010 at 4:57 PM, ammonkey <email address hidden> wrote:

> still big memory leeks when u're browsing images with gloobus-preview it
> eat all the ram of you computer until freeze crash of the system.
> Nothing is freed from a preview to another. This render gloobus-preview
> barely usable.
>
> --
> Memory leak
> https://bugs.launchpad.net/bugs/522384
> You received this bug notification because you are a member of Gloobus
> Developers, which is the registrant for gloobus-preview.
>
> Status in Gloobus Preview: In Progress
>
> Bug description:
> I've already reported this here
> https://bugs.launchpad.net/gloobus-preview/+bug/505644/comments/3 for pdf
> files , but now I noticed that it happens with any kind of files
> opened a folder with 2 images, after 20-30 switches got 24% of memory usage
> of my 4Gb
> some files eat less memory, other more
> rev173
>
>
>

[ammonkey (am-monkeyd)]

seems fixed since rev 249 thx Jordi
if anyone else can confirm, we can close this bug :)