Comment 16 for bug 293464

Right, so its not a cairo bug at all, the problem I found with the 1.5.1 version seems to be a coincidence. It seems to be a glade bug? I removed a child from an eventbox in a gtk::dialogue, and then destroyed the dialogue.

Test case, including 2 glade files, follows:
<--------->

NG_PATH = "NewGame.glade"
MS_PATH = "MapSettings.glade"
require 'libglade2'

class NewMapDialogue

 attr_accessor :selectMapDialogue, :resultHash

 def initialize

  @glade = GladeXML.new(NG_PATH, nil, "", nil, GladeXML::FILE) {|handler|method(handler)}
  @glade.get_widget("btnNew").signal_connect("clicked") { SelectMapDialogue.new }
  dialogue = @glade.get_widget("windowNewGame")

  dialogue.run{|response|

   #Here we invoke the garbage collector in order to force the bug to show
   #itself at a predictable location, and as early as possible.
   GC.start
   dialogue.destroy

  }

 end

end

class SelectMapDialogue

 attr_reader :resultHash

 def initialize

  @glade = GladeXML.new(MS_PATH, nil, "", nil, GladeXML::FILE) {|handler|method(handler)}
  @glade.get_widget("msGenerate").signal_connect("clicked") { }
  dialogue = @glade.get_widget("windowMapSettings")

  #HERE IS WHERE I REMOVE A CONTROL FROM AN EVENT BOX WHICH WAS ORIGINALLY PLACED THERE BY GLADE
  #IS THE GC GOING AFTER IT TWICE? ONCE WHEN IT IS REMOVED, AND AGAIN WHEN THE GLADE WINDOW IS DESTROYED?
  @glade.get_widget("eventBoxPreview").remove(@glade.get_widget("eventBoxPreview").child)

  dialogue.run{|response|

   GC.start
   dialogue.destroy

  }

 end

end

n = NewMapDialogue.new