To: sven.luther at wanadoo.fr
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: <20030917130832.GA7523 at iliana>
References: <20030917101503.GA6265 at iliana>
	<16232.22901.52195.482854@akasha.ijm.jussieu.fr>
	<20030917130832.GA7523@iliana>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20030917233243Z.garrigue at kurims.kyoto-u.ac.jp>
Date: Wed, 17 Sep 2003 23:32:43 +0900
From: Jacques Garrigue <garrigue at kurims.kyoto-u.ac.jp>
Lines: 33

From: Sven Luther <sven.luther at wanadoo.fr>

> On Wed, Sep 17, 2003 at 02:54:13PM +0200, Olivier Andrieu wrote:
> >  Sven Luther [Wednesday 17 September 2003] :
> >  > > Objects that appear on the caml side have an extra reference, so they
> >  > > are not GTK-finalized when they are destroyed, but later, when they
> >  > > are caml-finalized.
> >  > 
> >  > Err, so a destroyed object would have a refcount of 1 ?
> > 
> > Yes, but the converse is not true.
> 
> For object not created by ocaml but created indirectly, right ? Does
> this matter ? Do we even have access to such objects, as they are not GC
> roots or something such ? I guess we have access to them indirectly, but
> then the ocaml binding giving us access to them should also increment
> ref counter or something such, no ?

A newly created object only referenced from caml has a refcount of 1.

And a destroyed object may have an arbitrary refcount anyway.
In good situations this is expected to be 1 (as all referers should
have registered callbacks), but this not a requirement.
Moreover caml may hold several pointers on the same object.

I repeat, the only positive way to know that an object has been
destroyed is to listen to its destroy signal. This might be the right
thing to do in caml too, but this would certainly be heavy.

Maybe we should ask for a flag in the object, but it is not there
currently.

Jacques