Re: [Vala] array memory leak?
Anyone who can give a hint why test 1 eats up memory and test 2 do not? I was not able to find a explanation for this behaviour for myself. -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
Are you sure it's not because optimizations? No I'm not sure :-) I simply don't understand the behaviour differences between test 1 and test 2. But I'm curious to understand what's the reason for this. Try to put Dummy1 method in external compile unit(i.e. different .vala and .c file) and you should get better results. Tried, no changes :-( Maybe I should simply trust Vala/GLib and consider my test code as an artificial provocation of an error that do not exist in practice. -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
You have to provide more details. What's your method of testing whether memory used by Dummy1 has been freed or not? RSS is at 110 MB here during the loop in either case. I looked at RSS as you did. glibc does not and cannot immediately return every freed block back to the system. Some blocks cannot be freed because they are just gaps between heap-allocated regions and some blocks are intentionally not freed to speed up following allocations. Damn! My background is embedded programming and I'm relatively new to Vala/GLib so I thought g_free is only an other name or a very thin wrapper for free. I really think this is the solution. My appologize for unecessary stealing yours and others time :-( You can normally trust valgrind's output to check whether your application or library has memory leaks. I will do this for now on :-) -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
On Fri, 2014-03-07 at 12:49 +0100, Ulink wrote: glibc does not and cannot immediately return every freed block back to the system. Some blocks cannot be freed because they are just gaps between heap-allocated regions and some blocks are intentionally not freed to speed up following allocations. Damn! My background is embedded programming and I'm relatively new to Vala/GLib so I thought g_free is only an other name or a very thin wrapper for free. I really think this is the solution. 'g_free' _is_ (normally) just a wrapper for 'free'. Please note that I'm talking about glibc, not GLib. There is also a memory allocator in GLib, GSlice, which can have its own share of internal fragmentation. However, that's not used for plain strings and arrays. Regards, Jürg ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
'g_free' _is_ (normally) just a wrapper for 'free'. Please note that I'm talking about glibc, not GLib. There is also a memory allocator in GLib, GSlice, which can have its own share of internal fragmentation. However, that's not used for plain strings and arrays. Ok, but the fact that only using a glib message loop removes the leak is a strong clue that glib has something to do with the effect. Anyway, thanks for the clarifications, I will trust vala/glib/glibc and valgrind from now on and I will double or triple check everything before shouting out i've found a memory leak i've found a memory leak ;-) -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
Am 06.03.2014 01:07, schrieb Nor Jaidi Tuah: Most probably it's the optimizing behaviour of the memory allocator and has got nothing to do with the vala compiler. I don't think this is the case. If you call Dummy2(20), after returning from this function there are approximately 60MB of RAM already used until the program ends. Say LOOPS is 100.000.000 instead of 1.000.000 there are 6GB lost and my PC starts massive swapping. Looks like a memory leak, smells like a memory leak, Of course the memory leak per loop is small and my test functions are a little bit academic (LOOPS is very big), but the leak IS 0 and one is not able to say how big LOOPS is in real life. -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
Am 05.03.2014 23:01, schrieb Steven Oliver: What version libgee are you using? The one installed with Ubuntu saucy (13.10): 0.8.2 (dpkg says) Anyway, valac which saucy uses is not that old (0.20.1) and my Dummy() functions shows the memory leak with standard vala arrays (no gee involved here I think?) -- Bernhard ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
On 06/03/2014 09:59, Ulink wrote: I don't think this is the case. If you call Dummy2(20), after returning from this function there are approximately 60MB of RAM already used until the program ends. Say LOOPS is 100.000.000 instead of 1.000.000 there are 6GB lost and my PC starts massive swapping. Looks like a memory leak, smells like a memory leak, Of course the memory leak per loop is small and my test functions are a little bit academic (LOOPS is very big), but the leak IS 0 and one is not able to say how big LOOPS is in real life. Can you please report a bug? Thanks. ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
On Wed, 2014-03-05 at 19:17 +0100, Ulink wrote:
Consider the following (dummy) functions which shows memory leaks here
(valac 0.20.1 on ubuntu saucy 64Bit). It seems the problem exists with
Gee.ArrayList too. May someone confirm this?
According to valgrind 3.9.0, there are no leaks with this test code on
my system (up-to-date Linux on x86-64). I've tested with valac 0.20.1
and valac 0.22.1.
void main() {
Dummy1(100);
Dummy2(20);
Dummy3();
}
==20163== LEAK SUMMARY:
==20163==definitely lost: 0 bytes in 0 blocks
==20163==indirectly lost: 0 bytes in 0 blocks
==20163== possibly lost: 4,748 bytes in 85 blocks
==20163==still reachable: 37,264 bytes in 170 blocks
==20163== suppressed: 0 bytes in 0 blocks
'possibly lost' and 'still reachable' are all related to GObject
initialization and I'm just missing suppression lists for this.
If you're still seeing memory leaks on your system, please include a
full test case (i.e., including main) and provide a corresponding leak
report from valgrind or another leak checker.
Regards,
Jürg
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
Hi Juerg,
According to valgrind 3.9.0, there are no leaks with this test code on
my system (up-to-date Linux on x86-64). I've tested with valac 0.20.1
and valac 0.22.1.
Confirmed, valgrind shows no memory leak. I'm puzzled.
void Dummy1(int len)
{
const int LOOPS=100;
string[] dummy = new string[LOOPS];
for(var xx=0; xxLOOPS; xx++)
dummy[xx]=string.nfill(len, 'x');
}
//test 1: memory used by Dummy1 still used after return from Dummy1
int main(string[] args)
{
Dummy1(100);
for(;;);
return 0;
}
//test 2: memory used by Dummy1 FREED after return from Dummy1. WTF?
int main(string[] args)
{
Dummy1(100);
MainLoop loop = new MainLoop ();
loop.run();
return 0;
}
WTF? Is there a hidden garbage collector within the main loop or what?
Im TOTALLY puzzled now. Seems I have much to learn left, someone
illuminate me PLEASE ;-)
--
Bernhard
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] array memory leak?
Consider the following (dummy) functions which shows memory leaks here
(valac 0.20.1 on ubuntu saucy 64Bit). It seems the problem exists with
Gee.ArrayList too. May someone confirm this?
//memory leak if len120 (nfill ist NOT the problem)
//NO memory leak if len=120
void Dummy1(int len)
{
const int LOOPS=100;
string[] dummy = new string[LOOPS];
for(var xx=0; xxLOOPS; xx++)
dummy[xx]=string.nfill(len, 'x');
}
//memory leak if len24 (nfill ist NOT the problem)
//NO memory leak if len =24
void Dummy2(int len)
{
const int LOOPS=100;
string[] dummy={};
for(var xx=0; xxLOOPS; xx++)
dummy+=string.nfill(len, 'x');
}
class CDummy : GLib.Object
{
private int member;
public CDummy(int param) { member=param; }
}
void Dummy3() //memory leak
{
const int LOOPS=100;
CDummy[] dummy = new CDummy[LOOPS];
for(var xx=0; xxLOOPS; xx++)
dummy[xx] = new CDummy(xx);
}
--
Bernhard
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] array memory leak?
What version libgee are you using?
—
Sent from Mailbox for iPhone
On Wed, Mar 5, 2014 at 1:17 PM, Ulink ul...@gmx.at wrote:
Consider the following (dummy) functions which shows memory leaks here
(valac 0.20.1 on ubuntu saucy 64Bit). It seems the problem exists with
Gee.ArrayList too. May someone confirm this?
//memory leak if len120 (nfill ist NOT the problem)
//NO memory leak if len=120
void Dummy1(int len)
{
const int LOOPS=100;
string[] dummy = new string[LOOPS];
for(var xx=0; xxLOOPS; xx++)
dummy[xx]=string.nfill(len, 'x');
}
//memory leak if len24 (nfill ist NOT the problem)
//NO memory leak if len =24
void Dummy2(int len)
{
const int LOOPS=100;
string[] dummy={};
for(var xx=0; xxLOOPS; xx++)
dummy+=string.nfill(len, 'x');
}
class CDummy : GLib.Object
{
private int member;
public CDummy(int param) { member=param; }
}
void Dummy3() //memory leak
{
const int LOOPS=100;
CDummy[] dummy = new CDummy[LOOPS];
for(var xx=0; xxLOOPS; xx++)
dummy[xx] = new CDummy(xx);
}
--
Bernhard
___
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] array memory leak?
Most probably it's the optimizing behaviour of the memory allocator and has got nothing to do with the vala compiler. You should worry only if the leak grows and grows when the program is running. Any leak reported by a profiler at the end of a run shouldn't be trusted. 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
