I think I solved the problem, and it turned out to have nothing to do with GTK. I had static vars set up to cache the current canvas pointer. This was hanging around and causing the crash. Everything seems to be working fine now. On Sun, Jan 18, 2004 at 07:54:47PM +0000, Graham Swallow wrote: > Me too. > > My framework is libs_apps_YEAR-MM_DD.tgz at > http://homepage.ntlworld.com/information-cascade/baks/ > The gtk code is in src/lib_base2/gtk_1/ > > I think I fixed my problem by realising that GTK destroys its > own widget, THEN tells with the "destroy" callback, so that > C++ can release its storage WITHOUT REFERRING TO GTK > > The GTK widget object's memory has been free()d, but you are > still using it, which either reports "not a valid object", > or corrupts indirect memory, and the program trips up LATER. > > When an upper container is deleted, its children get AUTO deleted, > so you must avoid deleting them, but delete the C++ objects. > > I also had an issue with signal_disconnect_by_data(). > I'd claim it still happens, but have stopped calling it (leak). > > -OR- > > An alternative phase I went through, was when C++ deleted its > object, when the GTK object is fully alive. > > Then GTK calls back, with the deleted objects pointer > ... chaos ... > > -Different ways- > > Different designs require opposite senses. Should your code > delete the widget before or after GTK? Do you tell it, or > does it tell you? > > Reference counts can split widget deconstruction into > two halves. The DISPLAYED widgets reduction to a skeleton, > and later free(widget), with the C++ objects delete somewhere. > > I do tend to NOT do a refcount on GTK objects, even though I keep > a pointer to them. My excuse is that I should not have received > a "1" count in the first place, which gets absorbed by the PACK > action (ASIDE check how TCL does this - it's magically sensible, > and NOT how Python does it). So I do nothing (and it now works). > > > Graham > Information-Cascade (at) ntlworld.com > > > > Message: 1 > > Date: Sun, 18 Jan 2004 00:42:46 -0800 > > From: The Surprises <thesurprises1@xxxxxxxxxxx> > > To: gtk-list@xxxxxxxxx > > Subject: Destroying widgets properly > > > > Hello, > > I am getting mysterious and inconsistent crashes in my gtk program > > (ie it isn't crashing in the same spot every time), and > > I believe it has something to do with how I am destroying a set of > > widgets. I have an hbox (HB) packed into a vbox (VB). HB has many > > widgets packed inside of it, most of which are also created/maintained > > in their own C++ classes. One of the widgets is a GnomeCanvas, and it > > itself has many GnomeCanvasItem children, nearly each maintained in > > seperate C++ classes as well. At times, I need to entirely remove HB > > and all of it's children including the canvas and all of it's children. > > I then recreate everything from scratch and pack into VB. Actually the > > destroy seems to work OK. It is when I try to recreate all the widgets > > that I get the core dump. > > > > I tried having each class destructor first delete it's children (with a > > 'delete'), then destroy it's own widget (in the case of the > > GnomeCanvasItems, using GTK_OBJECT_DESTROY and casting the CanvasItem). > > I thought this made the most sense since you want to delete the children > > first before you delete the parent or you'll have children pointing to > > parents that no longer exist. I also tried reversing the order as well > > but get the same result. I get error messages like this: > > > > GLib-GObject-WARNING **: invalid uninstantiatable type > > `gint64' in cast to `GtkObject' > > > > Gtk-CRITICAL **: file gtkobject.c: line 358 > > (gtk_object_destroy): assertion `GTK_IS_OBJECT (object)' failed > > > > GLib-GObject-WARNING **: invalid cast from `(null)' to > > `GtkObject' > > > > Gtk-CRITICAL **: file gtkobject.c: line 358 > > (gtk_object_destroy): assertion `GTK_IS_OBJECT (object)' failed > > > > > > I tried just doing a destroy on HB but get the same results. It seems > > like I'm leaving something behind. It works a few times, then crashes. > > Or it crashes on the first try. > > > > Thanks for any help > > Jason > > > > > > --__--__-- > > > > _______________________________________________ > > > > gtk-list@xxxxxxxxx > > http://mail.gnome.org/mailman/listinfo/gtk-list > > > > > > End of gtk-list Digest _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
