Memory leak

Bug #522384 reported by Alexandr Grigorcea on 2010-02-15
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gloobus-preview
Critical
BadChoice

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) wrote :

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 ;)

Changed in gloobus-preview:
status: New → Confirmed
importance: Undecided → High
importance: High → Critical
assignee: nobody → Jordi Puigdellívol (jordi-gloobus)
milestone: none → 0.5
Alexandr Grigorcea (cahr-gr) wrote :

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) 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!

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) 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

Alexandr Grigorcea (cahr-gr) wrote :

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) wrote :

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) wrote :

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

BadChoice (guitarboy000) on 2010-02-20
Changed in gloobus-preview:
status: Confirmed → In Progress
ammonkey (am-monkeyd) 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.

Alexandr Grigorcea (cahr-gr) wrote :

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) wrote :

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

Balló György (ballogy) on 2015-01-06
Changed in gloobus-preview:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers