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
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 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
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
'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
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
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
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
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
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 =
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)
{
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
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
13 matches
Mail list logo
