Re: [Vala] Gdk.RGBA in text tag - possible leak?



Gesendet: Montag, 18. Mai 2015 um 18:19 Uhr
Von: "Al Thomas"

From: Gilzad Hamuni
Sent: Monday, 18 May 2015, 16:16

 Gesendet: Montag, 18. Mai 2015 um 16:12 Uhr
 Von: "Al Thomas"
 As a hint I would try removing 'weak':

 Gdk.RGBA tmpColor = Gdk.RGBA();

Thanks Al,

if I understand correctly, then there's no use for 'weak' there as 
the scope for that declaration ends with the program. But it doesn't affect 
the memory consumption in the loop. I really went ahead and removed it now just 
to be sure. 


Hmm, Vala memory management is scope based reference counting. See
https://wiki.gnome.org/Projects/Vala/Tutorial#Destruction
[...]
So I don't understand why your code in the loop after the comment
//when done, delete everything
is necessary.

Hi Al,

I have to clear the buffer's tag table and its text to ensure that the raising memory consumption doesn't 
from from there. However, in this example I didn't have to iterate through the tag_table for just one tag. 
That's a leftover, I've refactored that.

Or why you are using weak parameter types (generics) in Gee.ArrayList.
Since I wasn't sure which portion of my code would not free memory, I found it acceptable to have Vala/Glib 
attempt to free memory "too" often for the moment (obviously Vala avoids double-freeing itself). I realize 
the weak keyword makes no difference here memory-wise (and runtime-wise probably for the worse). 
"Over-engineered" puts it well.

Still reading from "tag.foreground_rgba" consumes more
memory through the loop.
to_string() doesn't just read, it will need memory to create the string. I believe this should be freed 
when it
goes out of scope

I see, so my comment "without buffering" was incorrect for that line. But I can say that printing
(42).to_string()
won't raise the memory usage in that loop.

You may still have found a bug, but try refactoring your code a bit more first.

Yes, there was too much going on for a showcase, sorry. I hope the attached file does a better job showing 
the possible leak. [1] is the vgdump for the case where I suspect leaking. [2] is the vgdump when not 
accessing tag.foreground_rgba .


Thanks again & best,

gilzad


[1] https://gist.github.com/anonymous/f1aead08848226949f48
[2] https://gist.github.com/anonymous/27dbad1f09568a1e8211

Attachment: gdk_rgba.vala
Description: Text Data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]