On Sat, 2013-12-14 at 15:25 +0800, Nor Jaidi Tuah wrote:
> Dear all,
>
> I had a memory leak in my app that I traced to
> a delegate variable. Something like this:
>
> class X {
> delegate void Delegate ();
> Delegate d;
>
> public void xx () {
> d = () => { do_stuff ();};
> }
> }
>
> Given the above, the following will leak memory:
>
> {
> new X(). xx ();
> }
>
> I think this is because there is an unavoidable
> reference cycle between d and the X object. Is
> this correct? If not, then it may be a vala bug.It's correct. > I can fix the memory leak by setting d to null > before the X object gets unreffed (this makes > it sound like a vala bug). Unfortunately Vala can't know that this is a safe thing to do. It would require some very advanced analysis, and would break completely in some very common situations (like if the field weren't private, or d could also be set somewhere else with a value which didn't cause a reference count) which would mean a class of *very* difficult to diagnose and understand. Instead, you might want to consider making the field unowned, and maybe using a regular method instead of a closure just to be sure. -Evan
signature.asc
Description: This is a digitally signed message part
_______________________________________________ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
