From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8727a81126dc209a
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-09-23 18:21:22 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!sccrnsc03.POSTED!not-for-mail
From: "Jeff C," <nolongersafeto@userealemailsniff.com>
Newsgroups: comp.lang.ada
References: <2PN9b.1478$I9.42@newsfep4-winn.server.ntli.net>
 <eKKbb.2024$jJ3.32654@newsfep4-glfd.server.ntli.net> <uad8v8x5k.fsf@nasa.gov>
 <R15cb.2820$jJ3.43467@newsfep4-glfd.server.ntli.net>
Subject: Re: Problem with memory leaks in Glade and GLADE
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <mk6cb.559062$Ho3.98461@sccrnsc03>
NNTP-Posting-Host: 66.31.4.164
X-Complaints-To: abuse@comcast.net
X-Trace: sccrnsc03 1064366482 66.31.4.164 (Wed, 24 Sep 2003 01:21:22 GMT)
NNTP-Posting-Date: Wed, 24 Sep 2003 01:21:22 GMT
Organization: Comcast Online
Date: Wed, 24 Sep 2003 01:21:22 GMT
Xref: archiver1.google.com comp.lang.ada:42830
Date: 2003-09-24T01:21:22+00:00
List-Id: <comp.lang.ada>


"Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message
news:R15cb.2820$jJ3.43467@newsfep4-glfd.server.ntli.net...
> Stephen Leake wrote:
> > Yes. The GtkAda list is quite helpful. See
> > http://libre.act-europe.fr/GtkAda/ for info on how to subscribe (in
> > the Authors section).
>
> OK.  I've been looking at the list.  Useful to keep in touch with.
>
> Unfortunately (?) I have found the leak problems are mirrored in the
> C version of the demo code "gtk-demo".  This code also sucks in RAM each
time
> the pointed enters the main selection window, (as well as taking in
> a megabyte or two extra each time a function is activated).


Not sure this is applicable but I remembered seeing something about the glib
free routines

http://docs.linux.cz/gtk-faq/x672.html

Why does GTK+/GLib leak memory?
It doesn't. Both GLib and the C library (malloc implementation) will cache
allocated memory on occasion, even if you free it with free().

So you can't generally use tools such as top to see if you are using free()
properly (aside from the very roughest of estimations, i.e. if you are
really, really screwing up top will show that, but you can't distinguish
small mistakes from the GLib/malloc caches).

In order to find memory leaks, use proper memory profiling tools.