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

[Al Thomas <astavale yahoo co uk>]

----- Original Message -----
> From: Gilzad Hamuni <gilli4 gmx net>
> Cc: Vala-list <vala-list gnome org>
> Sent: Tuesday, 19 May 2015, 20:35
> Subject: Aw: Re: [Vala] Gdk.RGBA in text tag - possible leak?
>
> 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.


OK. I understand the methodology - eliminate possibilities until you end up with the
one that causes the memory leak. Are you saying the if you don't manually clear
the buffer's tag table and its text you get a second memory leak? From what I 

understand you have done the work and found the line that causes the leak. So there
is no need to continue freeing the buffer manually?


> But I can say that printing
> (42).to_string()
> won't raise the memory usage in that loop.

42 is a constant. It doesn't change during the running of the program, but 

fair enough I understand.


> [1] https://gist.github.com/anonymous/f1aead08848226949f48


This is useful. From the Valgrind output you have linked to above
I think you must be referring to this section:
 

==7390== 269,504 bytes in 8,422 blocks are definitely lost in loss record 6,298 of 6,298
==7390== at 0x4C2935B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7390== by 0x6B46940: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.4)
==7390== by 0x6B5C49D: g_slice_alloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.4)
==7390== by 0x6B5CA10: g_slice_copy (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.4)
==7390== by 0x68B610F: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.4)
==7390== by 0x68C0317: g_object_get_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.4)
==7390== by 0x68C0726: g_object_get (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3600.4)
==7390== by 0x401ADC: _vala_main (gdk_rgba.vala:37)
==7390== by 0x402129: main (gdk_rgba.vala:4)


This is suggesting line 37 of your program is causing the problem. Line 37 is:
stdout.printf(tag.foreground_rgba.to_string()+"\n");

and from the C output from --save-temps in valac this produces the following C:
#line 200 "gdk_rgba.c"
{
FILE* _tmp25_ = NULL;
GtkTextTag* _tmp26_ = NULL;
GdkRGBA* _tmp27_ = NULL;
GdkRGBA* _tmp28_ = NULL;
gchar* _tmp29_ = NULL;
gchar* _tmp30_ = NULL;
gchar* _tmp31_ = NULL;
gchar* _tmp32_ = NULL;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp25_ = stdout;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp26_ = tag;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
g_object_get (_tmp26_, "foreground-rgba", &_tmp27_, NULL);
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp28_ = _tmp27_;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp29_ = gdk_rgba_to_string (_tmp28_);
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp30_ = _tmp29_;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp31_ = g_strconcat (_tmp30_, "\n", NULL);
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_tmp32_ = _tmp31_;
#line 37 "/home/al/software_projects/gdk_rgba.vala"
fprintf (_tmp25_, "%s", _tmp32_);
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_g_free0 (_tmp32_);
#line 37 "/home/al/software_projects/gdk_rgba.vala"
_g_free0 (_tmp30_);
#line 232 "gdk_rgba.c"
}


269,504 bytes in 8,422 blocks is 32 bytes per block.
So 32 bytes for each call to get the tag.foreground_rgba
value from the GObject? Hmm, I don't understand enough
about this to be certain what is going on. Anyone else?

Al