Delivered-To: garrigue at math.nagoya-u.ac.jp Authentication-Results: mailhost.math.nagoya-u.ac.jp sender=lablgtk-bounces at yquem.inria.fr; domainkey=neutral (no query protocol specified; no policy for yquem.inria.fr) Delivered-To: lablgtk at yquem.inria.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=R9mfgke+Boo3v0sQfoDDuSKZrL/a+6fY0PfQaZwNrAk=; b=ZS3mpzOC27zJhc++aduimHqlirseROnr3y19pN8tSLZC2PsMw8TjAdFaZ1GAm/RxCP FVuXfAU3VPY9tZuH4Ib4qExvKwR/sXZr+uYwVUctqq8EtQnJUB7rrDLe3UmmBWCnanpt RKpipWt8Z0VNpoN3yCiBnowAFh1egJbJKfA1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=oGO4WINrLvrw/KwjrI07YBkicXQdeetuj0cICJ2oB2fiRlDMz2NENG704sIho2/+B4 2xoaDhmmtVF4hUqyQeEEw39iiLdmdRL318PszvogcSHVH95YstOkAuNICCqwjLJ2zTr4 Vl1+4VlOSvV3UsMMG2HeJlM8ysEkI2E/06YEE= Message-ID: Date: Sun, 26 Oct 2008 22:45:26 -0400 From: "Jacques Le Normand" To: lablgtk at yquem.inria.fr Subject: Re: [Lablgtk] memory leak, destroying widgets In-Reply-To: MIME-Version: 1.0 References: <20081027.112828.78704204.garrigue@math.nagoya-u.ac.jp> Content-Type: multipart/mixed; boundary="===============1391004793==" Mime-version: 1.0 --===============1391004793== Content-Type: multipart/alternative; boundary="----=_Part_19366_27222524.1225075526793" ------=_Part_19366_27222524.1225075526793 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The same thing happens (the number keeps going up) here's the diff ... container_clear vbox; Gc.full_major (); print_endline (string_of_float (Gc.allocated_bytes ())); ... P.-S. sorry Jacques if you receive this message twice, I forgot to cc the list the first time --Jacques On Sun, Oct 26, 2008 at 10:40 PM, Jacques Le Normand wrote: > I get the same result (the number keeps going up) > here's the diff > > ... > container_clear vbox; > Gc.full_major (); > print_endline (string_of_float (Gc.allocated_bytes ())); > ... > > > > On Sun, Oct 26, 2008 at 10:28 PM, Jacques Garrigue < > garrigue@math.nagoya-u.ac.jp> wrote: > >> From: "Jacques Le Normand" >> >> > I'm getting a memory leak in my program because, when I destroy a >> widget, >> > the memory does not get freed. I thought it would be done automatically >> when >> > I call #remove from the container, but this does not seem to be the >> case. >> > How can I destroy my widgets and make sure the memory is cleared? I've >> tried >> > 2 or 3 different ways, with the same result. >> >> You should use Gc.full_major, to ensure that all finalizers are >> called. >> Note however that, in byte code, a variable referenced in the >> environment (either function argument or let-definition) cannot be >> freed until you leave the function. >> It should be ok to add a Gc.full_major call in your timeout. >> >> Jacques >> >> >> > Here is a program that creates and destroys 100 GEdit.entry every 200ms. >> At >> > every iteration, I call Gc.allocated_bytes . The number printed keeps >> going >> > up (showing that there is a memory leak.) I posted it a week ago. I've >> > gotten a couple of people to run it and they all get the same result. If >> > more people could run it to make sure, that would be greatly >> approciated. >> > cheers >> > --Jacques >> > >> > >> > let repeat n f = >> > let rec rep i = >> > if i = n then [] else (f () :: rep (i+1)) >> > in >> > rep 0 >> > >> > >> > let container_clear c = >> > List.iter c#remove c#all_children >> > >> > let _ = >> > let source_window = GWindow.window ~width:100 ~height:100 () in >> > let vbox = GPack.vbox ~packing:source_window#add () in >> > let inside = ref false in >> > let fill_vbox () = >> > if !inside then >> > () >> > else >> > begin >> > inside := true; >> > let add_entry () = >> > let ret = GEdit.entry () >> > in >> > vbox#pack (ret:>GObj.widget); >> > ret >> > in >> > container_clear vbox; >> > print_endline (string_of_float (Gc.allocated_bytes ())); >> > ignore(repeat 100 add_entry); >> > inside:=false >> > end >> > in >> > ignore(Glib.Timeout.add 200 (fun () -> fill_vbox (); true)); >> > source_window#show (); >> > GMain.Main.main () >> > > ------=_Part_19366_27222524.1225075526793 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The same thing happens (the number keeps going up)
here's the diff

...
    container_clear vbox;
    Gc.full_major ();
    print_endline (string_of_float (Gc.allocated_bytes ()));
...

P.-S. sorry Jacques if you receive this message twice, I forgot to cc the list the first time
--Jacques

On Sun, Oct 26, 2008 at 10:40 PM, Jacques Le Normand <rathereasy@gmail.com> wrote:

I get the same result (the number keeps going up)
here's the diff

...
    container_clear vbox;
    Gc.full_major ();

    print_endline (string_of_float (Gc.allocated_bytes ()));
...

On Sun, Oct 26, 2008 at 10:28 PM, Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> wrote:
From: "Jacques Le Normand" <rathereasy@gmail.com>

> I'm getting a memory leak in my program because, when I destroy a widget,
> the memory does not get freed. I thought it would be done automatically when
> I call #remove from the container, but this does not seem to be the case.
> How can I destroy my widgets and make sure the memory is cleared? I've tried
> 2 or 3 different ways, with the same result.

You should use Gc.full_major, to ensure that all finalizers are
called.
Note however that, in byte code, a variable referenced in the
environment (either function argument or let-definition) cannot be
freed until you leave the function.
It should be ok to add a Gc.full_major call in your timeout.

Jacques

> Here is a program that creates and destroys 100 GEdit.entry every 200ms. At
> every iteration, I call Gc.allocated_bytes . The number printed keeps going
> up (showing that there is a memory leak.) I posted it a week ago. I've
> gotten a couple of people to run it and they all get the same result. If
> more people could run it to make sure, that would be greatly approciated.
> cheers
> --Jacques
>
>
> let repeat n f =
> let rec rep i =
> if i = n then [] else (f () :: rep (i+1))
> in
> rep 0
>
>
> let container_clear c =
> List.iter c#remove c#all_children
>
> let _ =
> let source_window = GWindow.window ~width:100 ~height:100 () in
> let vbox = GPack.vbox ~packing:source_window#add () in
> let inside = ref false in
> let fill_vbox () =
> if !inside then
> ()
> else
> begin
> inside := true;
> let add_entry () =
> let ret = GEdit.entry ()
> in
> vbox#pack (ret:>GObj.widget);
> ret
> in
> container_clear vbox;
> print_endline (string_of_float (Gc.allocated_bytes ()));
> ignore(repeat 100 add_entry);
> inside:=false
> end
> in
> ignore(Glib.Timeout.add 200 (fun () -> fill_vbox (); true));
> source_window#show ();
> GMain.Main.main ()

------=_Part_19366_27222524.1225075526793-- --===============1391004793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk --===============1391004793==--