Re: [Vala] Help with Memory Leak
On Fri, 2013-05-17 at 07:23 -0400, Bruce Reidenbach wrote: > As they like to say, "old thread is old". > > I never was able to get a satisfactory answer from the gtk-app-devel list, > the only response being that the memory allocation/destruction model for > gtk was considered good enough. > > But then something curious happened. I compiled the code for the latest > Ubuntu (13.04) and the problem went away! The memory footprint is solid as > a rock, after several days of running. I know there's way too many > variables to figure out what happened (new kernal, new gtk, new valac), but > it appears the problem somehow was cured. I really doubt that the new > version of valac had anything to do with it since previously I could cause > the heap fragmentation to disappear if I commented out the command to > update the menu label. That's too bad; we don't know whom to compliment. Any way, thanks for sharing the good news. Nice day Nor Jaidi Tuah PRIVILEGED/CONFIDENTIAL information may be contained in this message. If you are neither the addressee (intended recipient) nor an authorised recipient of the addressee, and have received this message in error, please destroy this message (including attachments) and notify the sender immediately. STRICT PROHIBITION: This message, whether in part or in whole, should not be reviewed, retained, copied, reused, disclosed, distributed or used for any purpose whatsoever. Such unauthorised use may be unlawful and may contain material protected by the Official Secrets Act (Cap 153) of the Laws of Brunei Darussalam. DISCLAIMER: We/This Department/The Government of Brunei Darussalam, accept[s] no responsibility for loss or damage arising from the use of this message in any manner whatsoever. Our messages are checked for viruses but we do not accept liability for any viruses which may be transmitted in or with this message. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
As they like to say, "old thread is old".
I never was able to get a satisfactory answer from the gtk-app-devel list,
the only response being that the memory allocation/destruction model for
gtk was considered good enough.
But then something curious happened. I compiled the code for the latest
Ubuntu (13.04) and the problem went away! The memory footprint is solid as
a rock, after several days of running. I know there's way too many
variables to figure out what happened (new kernal, new gtk, new valac), but
it appears the problem somehow was cured. I really doubt that the new
version of valac had anything to do with it since previously I could cause
the heap fragmentation to disappear if I commented out the command to
update the menu label.
On Tue, Jul 17, 2012 at 7:18 AM, Bruce Reidenbach wrote:
> It undoubtedly is (thanks for the link, BTW). I have submitted a question
> on the gtk-app-devel mailing list to see if anyone over there has any
> advice on what could be done about heap fragmentation. I will provide an
> update over here when I have an answer, since I think it might be a good
> thing to have a small footprint for an indicator application.
>
> Thanks to everyone for helping me with this.
>
> Bruce
>
>
> On Mon, Jul 16, 2012 at 8:50 PM, Nor Jaidi Tuah
> wrote:
>
>>
>> > The problem with this code is that the actual labels on the menu did not
>> > update. I then added the following line to inform the menu entries of a
>> > change:
>> >
>> > radioItem [item].notify_property ("label");
>> > >
>> >
>> > and the heap size began its slow but steady increase again.
>>
>> Perhaps it is the glib "memory leak".
>>
>> http://developer.gnome.org/gtk-faq/stable/x702.html
>>
>> hand
>> Nor Jaidi Tuah
>>
>>
>> ___
>> vala-list mailing list
>> vala-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/vala-list
>>
>
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
It undoubtedly is (thanks for the link, BTW). I have submitted a question
on the gtk-app-devel mailing list to see if anyone over there has any
advice on what could be done about heap fragmentation. I will provide an
update over here when I have an answer, since I think it might be a good
thing to have a small footprint for an indicator application.
Thanks to everyone for helping me with this.
Bruce
On Mon, Jul 16, 2012 at 8:50 PM, Nor Jaidi Tuah wrote:
>
> > The problem with this code is that the actual labels on the menu did not
> > update. I then added the following line to inform the menu entries of a
> > change:
> >
> > radioItem [item].notify_property ("label");
> > >
> >
> > and the heap size began its slow but steady increase again.
>
> Perhaps it is the glib "memory leak".
>
> http://developer.gnome.org/gtk-faq/stable/x702.html
>
> hand
> Nor Jaidi Tuah
>
>
> ___
> vala-list mailing list
> vala-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/vala-list
>
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
> The problem with this code is that the actual labels on the menu did not
> update. I then added the following line to inform the menu entries of a
> change:
>
> radioItem [item].notify_property ("label");
> >
>
> and the heap size began its slow but steady increase again.
Perhaps it is the glib "memory leak".
http://developer.gnome.org/gtk-faq/stable/x702.html
hand
Nor Jaidi Tuah
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
I ran the following code for over 48 hours and there was no increase in the
heap size during that time:
char *label = radioItem [item].label;
> char *text = (item == 0) ? FORMAT [item].printf (val1)
> : FORMAT [item].printf (readable (val1),
> readable (val2));
> do *label++ = *text; while (*text++ != '\0'); // There's no strcpy
> () ... make our own!
>
The problem with this code is that the actual labels on the menu did not
update. I then added the following line to inform the menu entries of a
change:
radioItem [item].notify_property ("label");
>
and the heap size began its slow but steady increase again.
There are some things I could do to slow the increase of the heap (like
only updating the label if it changes, etc.), but this really only masks
the problem. Does anyone know of a method that can be used to defrag the
heap, or specify it's maximum size?
Bruce
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
> If this is really due to heap fragmentation, then there > must be a bug in the underlying malloc and free. I can't > imagine the memory keeps growing when all the dynamics are > due to getting and freeing memory for labels between > 10 to 36 characters in length. Initially, we will create > useless fragments. But, due to the pigeon-hole principle > (http://en.wikipedia.org/wiki/Pigeonhole_principle) > those fragments cannot remain entirely un-recyclable > even if "free" is very unthinkably simplistic and does not > merge adjacent fragments. After thinking it further, memory usage may indeed keep growing if "free" is very simplistic and does not merge adjacent fragments. hand Nor Jaidi Tuah ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On Thu, 2012-07-12 at 10:45 -0400, Bruce Reidenbach wrote: > After working with Jürg on this for the past week, and running some > experiments with valgrind and the memory profiler, it appears that what is > actually happening is heap fragmentation, which causes the heap to grow. > If I run the test case with the printf statment for 12 hours, the heap size > remains constant. If I run the normal case setting the radioMenuItem > label, the heap grows by about 1 MiB in a 9 hour period. If this is really due to heap fragmentation, then there must be a bug in the underlying malloc and free. I can't imagine the memory keeps growing when all the dynamics are due to getting and freeing memory for labels between 10 to 36 characters in length. Initially, we will create useless fragments. But, due to the pigeon-hole principle (http://en.wikipedia.org/wiki/Pigeonhole_principle) those fragments cannot remain entirely un-recyclable even if "free" is very unthinkably simplistic and does not merge adjacent fragments. hand Nor Jaidi Tuah ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
After working with Jürg on this for the past week, and running some experiments with valgrind and the memory profiler, it appears that what is actually happening is heap fragmentation, which causes the heap to grow. If I run the test case with the printf statment for 12 hours, the heap size remains constant. If I run the normal case setting the radioMenuItem label, the heap grows by about 1 MiB in a 9 hour period. Looking at the generated C code does not show anything strange, only a call to gtk_menu_item_set_label () with the new text label, which gets freed at the end of the method. So that brings up the question, is there a way of minimizing the amount of heap fragmentation? There are six menu labels which update once per second, and each label will vary between 10 to 36 characters in length. One method I can think of, but cannot seem to figure out the code for, would be to initially create a menu item with a long enough string (say, 64 characters) that I could over-write instead of having to call set_label(), which uses realloc(), like: char *label = radioItem [item].label; char *text = (item == 0) ? FORMAT [item].printf (val1) : FORMAT [item].printf (readable (val1), readable (val2)); do *label++ = *text; while (*text++ != '\0'); // There's no strcpy () ... make our own! The code compiles and runs, but the menu items do not actually update. Is there a signal that needs to be issued to inform the menu that labels have been updated? The other thought would be to periodically run a heap defrag routine, maybe once per minute, but I have not found a function that does that in the API. Bruce On Fri, Jul 6, 2012 at 6:17 PM, Jürg Billeter wrote: > > While (owned) is definitely useless here, this should not cause a memory > leak, and in a quick test valac appears to handle this correctly. > > Bruce, if you can provide a self-contained test case, I'll take a closer > look. > > Regards, > Jürg > > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
Jürg, I sent the source files to your email account. Bruce On Fri, Jul 6, 2012 at 6:17 PM, Jürg Billeter wrote: > On Fri, 2012-07-06 at 13:21 -0700, Evan Nemerson wrote: > > Get rid of (owned). That is used to transfer ownership of a reference, > > but g_menu_item_set_label doesn't steal the reference you pass it, so > > what ends up happening here is that GTK+ will copy the string you pass > > it, and since you told Vala that you want to transfer ownership it will > > not free the string when it goes out of scope, and you end up leaking > > it. > > While (owned) is definitely useless here, this should not cause a memory > leak, and in a quick test valac appears to handle this correctly. > > Bruce, if you can provide a self-contained test case, I'll take a closer > look. > > Regards, > Jürg > > ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On Fri, 2012-07-06 at 13:21 -0700, Evan Nemerson wrote: > Get rid of (owned). That is used to transfer ownership of a reference, > but g_menu_item_set_label doesn't steal the reference you pass it, so > what ends up happening here is that GTK+ will copy the string you pass > it, and since you told Vala that you want to transfer ownership it will > not free the string when it goes out of scope, and you end up leaking > it. While (owned) is definitely useless here, this should not cause a memory leak, and in a quick test valac appears to handle this correctly. Bruce, if you can provide a self-contained test case, I'll take a closer look. Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On Fri, 2012-07-06 at 14:27 -0400, Bruce Reidenbach wrote:
> Hello all,
>
> I am encountering a memory leak in an appindicator menu. The menu is made
> up of several RadioMenuItems that have their labels updated once per
> second. I have tracked the memory leak down to the following code, but
> cannot seem to be able to make any additional headway. The method "update"
> is called from several sources, and specifies the radio item and the values
> to update via a const array of FORMAT statements. If I comment out the
> code that sets the radio menu item label and un-comment the printf
> statement, the leak disappears. The leak is minor -- on the order of about
> 20 to 30 bytes per invocation -- but over time it adds up.
>
> I'm not sure if this is the correct forum for asking for help, or whether
> this is a problem with the gtk+-3.0 or appindicator3-0.1 packages, but I
> thought I'd see if anyone has any ideas in the Vala community first.
>
> Thanks,
> Bruce
>
> //
> -
> // Make results more readable by appending the appropriate metric unit to
> the data
> //
> -
>
> private const string suffix [] = { "bytes", "KiB", "MiB", "GiB", "TiB",
> "PiB", "EiB", "ZiB" };
>
> private string readable (float bytes) {
> foreach (string s in suffix) {
> if (bytes < 1024.0) {
> var format = (s == "bytes") ? "%.0f %s" : "%.1f %s";
> return format.printf (bytes, s);
> }
> bytes = bytes / 1024.0f;
> }
> return "%.1f YiB".printf (bytes);
> }
>
> //
> -
> // Menu update
> //
> -
>
> public void update (int item, float pct, float val1, float? val2 = 0.0f) {
> var text = (item == 0) ? FORMAT [item].printf (val1)
>: FORMAT [item].printf (readable (val1),
> readable (val2));
> radioItem [item].label = (owned) text; // Leaky?
Get rid of (owned). That is used to transfer ownership of a reference,
but g_menu_item_set_label doesn't steal the reference you pass it, so
what ends up happening here is that GTK+ will copy the string you pass
it, and since you told Vala that you want to transfer ownership it will
not free the string when it goes out of scope, and you end up leaking
it.
-Evan
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
Thomas, Thanks for the quick response. When I add the statement you mentioned, I get the following compilation error: SystemIndicator.vala:128.23-128.52: error: No reference to be transferred string old_text = (owned) radioItem [item].label; ^^ ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Help with Memory Leak
On 07/06/2012 08:27 PM, Bruce Reidenbach wrote:
> Hello all,
>
> I am encountering a memory leak in an appindicator menu. The menu is made
> up of several RadioMenuItems that have their labels updated once per
> second. I have tracked the memory leak down to the following code, but
> cannot seem to be able to make any additional headway. The method "update"
> is called from several sources, and specifies the radio item and the values
> to update via a const array of FORMAT statements. If I comment out the
> code that sets the radio menu item label and un-comment the printf
> statement, the leak disappears. The leak is minor -- on the order of about
> 20 to 30 bytes per invocation -- but over time it adds up.
[snip]
> -
> // Menu update
> //
> -
>
> public void update (int item, float pct, float val1, float? val2 = 0.0f) {
> var text = (item == 0) ? FORMAT [item].printf (val1)
>: FORMAT [item].printf (readable (val1),
> readable (val2));
> radioItem [item].label = (owned) text; // Leaky?
> //stdout.printf (text + "\n");
>
> var ptr = (int) (pct * 10.0f);
> if (selected == item) appIcon.set_icon_full (icons [ptr], NAME);
> }
I don't claim to actually understand the object model, but I have an idea:
It stands to reason that the label string is not properly freed. It
looks like, though ownership is transferred to radioItem, it does not
know about this, and no code to free the string is around.
Try adding a line
string old_text = (owned) radioItem [item].label;
This should have Vala take care of it?
Thomas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Help with Memory Leak
Hello all,
I am encountering a memory leak in an appindicator menu. The menu is made
up of several RadioMenuItems that have their labels updated once per
second. I have tracked the memory leak down to the following code, but
cannot seem to be able to make any additional headway. The method "update"
is called from several sources, and specifies the radio item and the values
to update via a const array of FORMAT statements. If I comment out the
code that sets the radio menu item label and un-comment the printf
statement, the leak disappears. The leak is minor -- on the order of about
20 to 30 bytes per invocation -- but over time it adds up.
I'm not sure if this is the correct forum for asking for help, or whether
this is a problem with the gtk+-3.0 or appindicator3-0.1 packages, but I
thought I'd see if anyone has any ideas in the Vala community first.
Thanks,
Bruce
//
-
// Make results more readable by appending the appropriate metric unit to
the data
//
-
private const string suffix [] = { "bytes", "KiB", "MiB", "GiB", "TiB",
"PiB", "EiB", "ZiB" };
private string readable (float bytes) {
foreach (string s in suffix) {
if (bytes < 1024.0) {
var format = (s == "bytes") ? "%.0f %s" : "%.1f %s";
return format.printf (bytes, s);
}
bytes = bytes / 1024.0f;
}
return "%.1f YiB".printf (bytes);
}
//
-
// Menu update
//
-
public void update (int item, float pct, float val1, float? val2 = 0.0f) {
var text = (item == 0) ? FORMAT [item].printf (val1)
: FORMAT [item].printf (readable (val1),
readable (val2));
radioItem [item].label = (owned) text; // Leaky?
//stdout.printf (text + "\n");
var ptr = (int) (pct * 10.0f);
if (selected == item) appIcon.set_icon_full (icons [ptr], NAME);
}
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
