Re: Gtk+ signal bug

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> The correct fix is really simple, in gtk_signal_handlers_destroy:
> 
>          if (handler->id > 0)
>             gtk_signal_handler_unref (handler, object);
> 
> should be:
> 
>          if (handler->id > 0)
>             {
>                handler->id = 0;
>                gtk_signal_handler_unref (handler, object);
>             }
> 
> [ There are two of these ]
That would likely do that trick, and may help others codes.


> But since I would not like to see gtk-- depend on a new release
> of GTK+, let me suggest a simple workaround:
> 
> All signal handlers are disconnected at destruction, so simply
> check
> 
>  GTK_OBJECT_DESTROYED (obj)
>
> when you are cleaning up after your proxy object, and skip
> the disconnection step in that case.

That one works.  Much less insane behavoir in gtk+ layer now.
This corruption seem to be causing all sorts of random bugs 
including gtk+ spontaineously quiting.  Considering there was bullet
proofing to catch ref==0, it must have been something very
obscure.  Basically it was breaking the gtk+ signal system 
completely because sometimes the freed handler got reused before
the stck unrolled causing completely unpredictable crashes.

>  
> [ The destroyed will probably go away in GTK+-1.4, but this
>   should work fine for now ]

Will there be something with a similar effect?  We don't need gtk+
to actually destroy the object, it is fine if it continues living.
(If a gtk+ object continues living and appears to the gtk-- system
later, we currently just consider it to be a new widget and create
a fresh wrapper.) We simply want to have the item removed from its 
container and break unnecessary dependencied because all C++ connections 
are about to go south.

(Making destroy less fatal will help us a lot in that the gtk+
object can't be destroyed with the proxy still alive would prevent
gtk+ from making walking wounded.)


> (In fact, for non-pathological cases, the explicit disconnections
> are unnecessary, since for unmanaged gtk-- objects, the GTK+ widget
> will be destroyed when the proxy is deleted, and for managed
> objects, the proxy object will not be deleted until the GTK+
> widget is finalized, which occurs after destruction.)

You are right that with managed objects, the explicit disconnect
never happens.  The invarient is that if gtk+ doesn't clean up
we will.  In managed objects, gtk+ sends notification to all
of our signals so that surpress their disconnects.  Thus the
only case this effects is the unmanaged ones.  Thus we never
had any problems with destory.  The gtk+ object always goes
before us and cleans up most of the stuff.

The unmanaged one is still pathological thought because if gtk+
emits a signal and we are in the dtor, we have class methods being
emitted on partially constructed objects.  There has really been
no way around that problem other than trying to get
our stuff cut off as soon as we can.  I guess I could try
surpressing the clean up of the gtk+ resources, but the clean up
was there for another reason.  It is necessary to clean up
our signals which share the same execution path.  The explicit disconnects 
to gtk+ are required also for the user requested disconnect.
Thus even if it is unnecessary busy work we will still need to do it.


Many thanks though, as this should likely stop all but
users doing something extremely nasty (and likely illegal).

--Karl