From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14882 invoked by alias); 24 Jan 2003 15:05:36 -0000 Mailing-List: contact guile-gtk-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: guile-gtk-owner@sources.redhat.com Received: (qmail 14794 invoked from network); 24 Jan 2003 15:05:34 -0000 Received: from unknown (HELO sunny.pacific.net.au) (203.25.148.40) by 172.16.49.205 with SMTP; 24 Jan 2003 15:05:34 -0000 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id h0OF5VKR022175 for ; Sat, 25 Jan 2003 02:05:31 +1100 (EST) Received: from localhost (ppp38.dyn228.pacific.net.au [203.143.228.38]) by wisma.pacific.net.au with ESMTP id CAA27420 for ; Sat, 25 Jan 2003 02:05:28 +1100 (EST) Received: from gg by localhost with local (Exim 3.35 #1 (Debian)) id 18c5OB-0000TA-00; Sat, 25 Jan 2003 01:05:03 +1000 To: guile-gtk@sources.redhat.com Subject: gtk-container-children memory leak From: Kevin Ryde Mail-Copies-To: never Date: Fri, 24 Jan 2003 15:05:00 -0000 Message-ID: <87wukuio68.fsf@zip.com.au> User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.1 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-q1/txt/msg00006.txt.bz2 I think gtk-container-children might be leaking memory. On a recent i386 debian and my build of guile 1.6.1, the following little program uses an apparently ever increasing amount of core (as shown by the "top" program). (use-modules (gtk gtk)) (define toplevel (gtk-window-new 'toplevel)) (gtk-container-add toplevel (gtk-label-new "foo")) (while #t (gtk-container-children toplevel)) I think gtk_container_children allocates a fresh GList for its return, which the caller is supposed to free. As far as I can tell that doesn't happen in gtk-glue.c etc. Inserting a g_list_free manually into sgtk_gtk_container_children seems to do the trick, but I'm not smart enough to tell how to get that done properly. It'd probably be good to allow either freeing or not. gtk_container_children and a prospective gdk_list_visuals should free, gtk_radio_button_group (which is a GSList) and a prospective gdk_window_peek_children (implementing gtk-window-children) shouldn't.