From: Olivier Andrieu MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <16232.13115.936897.972444 at akasha.ijm.jussieu.fr> Date: Wed, 17 Sep 2003 12:11:07 +0200 To: Sven Luther 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: <20030917080141.GA2325 at iliana> References: <20030916103137.GA25181 at redhat.com> <16231.2269.152007.823440@karryall.dnsalias.org> <20030916162604.GA30706@redhat.com> <20030917071141A.garrigue@kurims.kyoto-u.ac.jp> <20030917080141.GA2325@iliana> Sven Luther [Wednesday 17 September 2003] : > > On Wed, Sep 17, 2003 at 07:11:41AM +0900, Jacques Garrigue wrote: > > 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. > > Err, i thought that the gtk+ widget were reference-counted garbage > collected or something such ? They are, but "destroying" a widget doesn't mean "release its memory". From the GTK+ documentation : « The "destroy" signal asks all code owning a reference to an object to release said reference. So, for example, if you call gtk_object_destroy() on a GtkWindow, GTK+ will release the reference count that it owns; if you call gtk_object_destroy() on a GtkButton, then the button will be removed from its parent container and the parent container will release its reference to the button. Because these references are released, calling gtk_object_destroy() should result in freeing all memory associated with an object [ ... ] Freeing memory (referred to as finalization) only happens if the reference count reaches zero. » 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. -- Olivier