Hi,
as Juerg Billeter convinced me, this is not a memory leak but some
effect of glibc's and/or glib's memory management.
Forget it, my appologize for unecessary stealing yours and others time :-(
This only shows nothing more that Vala/GLib/Gtk is cool, alive and is
widely supported ;-)
--
Be
> '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 tha
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
> 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
Hi Tal,
> I know it's little desperate but could you:
No, of course its not :-)
Thanks for taking a look on this, I'm running out of ideas...
> 1. Post the generated C code?
See attached. Code looks ok for me, maybe g_free do something wrong (see
_vala_array_destroy)?
> 2. Try to replace strin
Hi Bernhard,
On Thu, 2014-03-06 at 11:00 +0100, Ulink wrote:
> //test 1: memory used by Dummy1 still used after return from Dummy1
> //test 2: memory used by Dummy1 FREED after return from Dummy1. WTF?
You have to provide more details. What's your method of testing whether
memory used by Dummy1 h
I know it's little desperate but could you:
1. Post the generated C code?
2. Try to replace string array with int array.
Tal
> Date: Fri, 7 Mar 2014 11:38:50 +0100
> From: ul...@gmx.at
> To: vala-list@gnome.org
> Subject: Re: [Vala] array memory leak?
>
> > Are
> 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
Are you sure it's not because optimizations?
Try to put Dummy1 method in external compile unit(i.e. different .vala and .c
file) and you should
get better results.
Tal
> Date: Thu, 6 Mar 2014 11:00:05 +0100
> From: ul...@gmx.at
> To: vala-list@gnome.org
> Subject: Re: [Vala]
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
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
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
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
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
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 a
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 Tu
What version libgee are you using?
—
Sent from Mailbox for iPhone
On Wed, Mar 5, 2014 at 1:17 PM, 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 confi
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 len<120 (nfill ist NOT the problem)
//NO memory leak if len>=120
void Dummy1(int len)
{
18 matches
Mail list logo
