warning: GRClosure invoking callback: already destroyed

i confirm.
a program in Ruby that uses glade, for every callback that should be called, prints:
warning: GRClosure invoking callback: already destroyed
and does not call the callback.
this only appeared in edgy.
 http://yasmin.technion.ac.il/svn-trac/ttime/ticket/28

Confirmed again. However, this doesn't seem to show up with libglade2-ruby's examples (in /usr/share/doc).

It might have something to do with these though:

/usr/lib/ruby/1.8/glib2.rb: line 55
  GLib-GObject-CRITICAL **:g_boxed_type_register_static: assertion
`g_type_from_name (name) == 0' failed
/usr/lib/ruby/1.8/glib2.rb: line 55
  GLib-GObject-CRITICAL **:g_param_spec_boxed: assertion
`G_TYPE_IS_BOXED (boxed_type)' failed
  GLib-GObject-CRITICAL **:g_object_class_install_property: assertion
`G_IS_PARAM_SPEC (pspec)' failed
/usr/lib/ruby/1.8/glib2.rb: line 55

Attached is fix from CVS

how i can apply this patch?

Preferably manually. Read the patch, it explains exactly what file needs to be modified and how.

This is also a problem in feisty. Applying the patch fixes the issue. I believe I can make a example program to demonstrate the bug if necessary.

Thanks for the patch. I've added the patch tag to attract attention of packagers. I have unsubscribed ubuntu-universe-sponsors, as this does not represent a new candidate revision (patch is not a debdiff). If a debdiff is generated to address this issue, please resubscribe ubuntu-universe-sponsors to request upload.

This issue has been fixed in Gutsy.

I believe that this issue (or a similar issue) is in gutsy. I was receiving this message too.

Going into libglade2.rb, I edited it to include:

@@ -40,6 +40,7 @@
     end

     if signal_proc
+ guard_source_from_gc(source)
       case signal_proc.arity
       when 0
         sig_conn_proc.call(signal) {signal_proc.call}
@@ -93,6 +94,20 @@

And it fixed the message. Note that I have no idea what I was doing, and I haven't tested this properly (and given that I have two files which should produce exactly the same parse tree, but behave differently), I think some slightly more rigorous testing is needed

I've reopened the bug, apologies if this is the wrong thing to do, I have a habit of screwing these things up.

I also see this in Gutsy.

The development system is upgraded from Feisty, and I had applied the original patch manually, but I deleted libglade2.rb and did a package reinstall to be sure I had the new Gutsy version.

Andy Owen's one-line fix has eliminated the problem, which was previously easily reproducible.

I also can confirm this error on gutsy with:

$ ruby -r gtk2 -e 'p Gtk::VERSION'
[2, 12, 0]
$ ruby --version
ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux]
$ uname -r
2.6.22-14-generic

Also here Andy Owen's patch fixes the problem.

I'm running into the same problem intermittently on Hardy Alpha 2

$ ruby -r gtk2 -e 'p Gtk::VERSION'
[2, 12, 3]
$ ruby --version
ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]
$ uname -r
2.6.24-2-generic

As with the previous comment for Gutsy, Andy Owen's patch seems to solve the problem.

Is there any word as to the status of this bugfix in Hardy? I don't mean to nag or harass, but this bug is quite important to me. I'm writing a piece of software that runs into this issue intermittently and unpredictably. Unfortunately, in this case, applying the patch myself isn't sufficient, since that won't help users.

I'm hopeful that this bug will be resolved in the next release, but I haven't noticed any activity related to it in a while, which is making me kind of nervous.

Hi,
Just for info, altough i found this page while browsing for help for that exact same error message with a ruby-gtk2 program, it went away when i installed libgnome2-ruby

I'm still seeing this bug in Hardy. And Owen's one-line patch still solves the problem.

Is there any reason we can't ship Owen's one-line patch?

This bug was first reported almost 2 years ago. If GTK itself had this problem, it would be considered a show-stopper. Why is it "Importance: Low" for a GTK binding?

@Ian

It has puzzled me, too. Perhaps the maintainer missed the part where the callbacks break, and thinks that the only trouble is that it is printing out the warning?

It's not as if use of Glade for GTK UIs is uncommon, lots of projects use Glade for the creation of smaller or static portions of their UI. The solution from Benjamin Thyreau seems to do the trick, but needing to install an additional package to fix a bug in a busted one it a terrible state of affairs.

For app developers waiting for a fix, the following hot-patch seems to work. Testing for a range of version numbers before patching might be a good idea.

require 'libglade2'

class GladeXML
 alias :connect_without_source_guard :connect
 def connect(source, target, signal, handler, data, after = false)
  guard_source_from_gc(source)
  connect_without_source_guard(source, target, signal, handler, data, after)
 end
end

Edgy has reached its end of life and this particular bug task is being set to Won't Fix.

"Edgy has reached its end of life and this particular bug task is being set to Won't Fix."

It has been nominated for versions after Edgy as well, and this bug as persisted for years - can we hope to see it accepted and fixed for those newer versions?

From what I understand, its a relatively simple fix - is there something else that is making it more complicated that I don't know about?