To: rich at annexia.org
Cc: lablgtk at kaba.or.jp
Subject: Re: Memory handling bug: cannot access fields in a combo box
 belonging to a dialog which has been destroyed
In-Reply-To: <20030916162604.GA30706 at redhat.com>
References: <20030916103137.GA25181 at redhat.com>
	<16231.2269.152007.823440@karryall.dnsalias.org>
	<20030916162604.GA30706@redhat.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20030917071141A.garrigue at kurims.kyoto-u.ac.jp>
Date: Wed, 17 Sep 2003 07:11:41 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 30

From: Richard Jones <rich at annexia.org>

> On Tue, Sep 16, 2003 at 02:58:05PM +0200, Olivier Andrieu wrote:
> > But the (caml) program _doesn't_ hold a reference on the entry until
> > you've called combo#entry.
> [...]
> 
> I understand your explanation, but I still think it's a bug! OCaml is
> supposed to shield me from the sorts of things that C programmers
> worry about.

I see your point, but actually this is not a problem of memory
management per se. There are two problems:
* calling a method on a destroyed object may fail fatally in some
  cases. I couldn't find a method in GTK which would tell me whether
  an object is already destroyed or not.
* since widgets are destroyed recursively, even if you could get an
  handle on the entry widget, it would already have been destroyed by
  that time, so there is very little you could do with it anyway.

The unability to tell whether an object is destroyed or not is a pain.
Fortunately, GTK makes sure that you don't get a segmentation fault,
but a reasonable(?) error message.

Then only way I know for sure to tell whether an object is destroyed
or not is to bind its destroy signal, but it would be impractical to
do it for every object. You can of course do it on an individual
basis.

Jacques