Re: [gDesklets] 0.36.[3, 4] memory leak, a.k.a. memory growth after reloading a desklet

[Ronny Lorenz <raumzeit gmx net>]

Sorry for beeing impatient about this memory issue.
I have to confess, that a reload of any desklet still results in memory 
growth.
However, somehow updating the desklets seems to work without leak now. I 
made a desklet that shows CPU consumption in a colored circular bargraph 
using some SVG in the <canvas> tag.
This was leaking even without reloading the desklet before I applied the 
patch to utils/render.c

I also tried to uncover a cause of the memory growth in case a desklet 
gets restartet. But it's quiet hard for me to go through the sources of 
gdesklets to find out what actually happens if I select
"Restart desklet" from the context menu. Since I ran gdesklets with 
valgrind and did not find any significant 'definite loss' of memory but 
a huge amount of 'possibly lost' memory, I have the suspicion
that maybe the garbage collector of python does not recognize to free 
pixelbuffers or other stuff allocated from gtk due to some circular 
references. Maybe explicitely deleting some gtk related objects
and then calling the garbage collector afterwards may work???
Regarding the above issue, see:

http://faq.pygtk.org/index.py?req=show&file=faq08.004.htp
and
http://article.gmane.org/gmane.comp.gnome.gtk+.python/2315/match=pixbuf

Anyway, as soon as I discover a possible solution I'll report back

Greetz

Ronny



On 01/31/2012 10:41 AM, Ronny Lorenz wrote:
> Hi gdesklets developers,
>
> I recently made a comment on the memory leak issues (see buglist on 
> launchpad).
> Since I don't know how often changes in the bugreports are recognized 
> by you, the developers, or whether or not you get automatically 
> informed about comments on already open bugs, I wanted to ask you 
> about your opinion about my findings regarding Bug #190894 and #19840.
>
> I already discussed this issue in short several months ago with Bjoern 
> Koch. At that time I experienced several gigs of RAM leaking with two 
> desklets displayed on my screen and some days of uptime.
> Back then, Bjoern suggsted me to look at a recent change in 
> utils/render.c (revision 142).
> There I found that despite changing gdk_pixbuf_scale_simple() to be 
> called everytime function render_to_image() is entered, the memory 
> occupied by the resulting GdkPixbuf *scale still gets free'd only, when
> one of width or height of the image changed. This then results in a 
> possible loss of the pointer to the scaled image when the function 
> returns and along with that in memory leaks.
> When I installed the new beta of 0.36.4 some days ago, I experienced 
> these memory leaks again. Thus, I had a look into the sources and saw 
> that this issue of not unreferencing the scaled image when its size 
> did not change is still present in the current sources.
> Is there any reason for that?
>
> Maybe one of you can have a look at the code, I also posted a patch in 
> the bug reports comments that simply comments out the condition that 
> checks for changed width || height.
>
> After I applied this patch to my running version of gdesklets, some 
> days of uptime and several desklets that change their appearance every 
> 500ms, it seems that the mysterious memory leak is gone for me!
>
> So maybe one of you can check if this is true in general and possibly 
> you can fix this before releasing version 0.36.4?
>
> Kind regards
>
> Ronny
>
>
>
> _______________________________________________
> gdesklets-list mailing list
> gdesklets-list gnome org
> http://mail.gnome.org/mailman/listinfo/gdesklets-list