Re: [java-gnome-hackers] Duplicating assertion `GDK_IS_WINDOW (window)' failed crash

[Andrew C. <an...@op...>]

On Tue, 2010-12-21 at 01:02 +1100, Andrew Cowie wrote:
> On Tue, 2010-12-21 at 00:05 +1100, Andrew Cowie wrote:
> > I still don't have any insight into what's going on with
> 
> Ok, I've made some progress.

Problem located (I think):

Our implementation for Widget's getWindow() did not take a Ref.

++

Turn on debugging:
Debug.MEMORY_MANAGEMENT = true
and
#define DEBUG_MEMORY_MANAGEMENT TRUE

Our GObject memory management code assumes (and requires) that when we
go to make a ToggleRef, we have one (and only one) normal Ref that we
own. The addToggleRef() code drops that normal Ref.

Meanwhile, our override for getWindow() just returned a the address.
Comparing to generated code, I realized our Override doesn't have a call
to bindings_java_memory_cleanup() [which I must admit never much liked
the name of].

Adding a g_object_ref() there appears to fix the problem.

Replacing the Override with some .defs to get normal generated code for
gtk_widget_get_window() [now that it exists; it didn't a few years ago]
also appears to work [since it generates the call to
bindings_java_memory_cleanup()]

++

Hm.

So while that will be a "fix", I'd like to rethink some of the code in
src/jni/bindings_java_memory.c. If we can consolidate
bindings_java_memory_cleanup() into bindings_java_memory_ref() I think
we'll be on the right track.

What worries me is that this is a general class of bug that we could be
exposed to all over the place whenever we've done an override. So the
problem needs to be engineered out.

If anyone working on this could confirm that the GdkWindows are still
getting finalized without crashing that'd be outstanding. The trick is
*is the GObject still being finalized*? It's easy to "add a
g_object_ref()" call anywhere, but if that means the Ref count never
drops to zero then you'll never get objects free()d and that wouldn't do
us any good, would it? :)

AfC
Sydney