Ruby/GTK应用笔记(3):垃圾回收

虽然垃圾回收应该属于RubyVM自动处理的事，但是一旦涉及到C扩展，情况就有些不同了。你可以在C扩展中申请资源并增加引用，导致VM无法回收资源－－当然，这个属于bug，不幸的是，Ruby/GTK不是bug free

以下列出一些我碰到的这样的bug，希望后来的朋友可以借此提前看到这个坑，不要踩到里面去。

1) Gdk::Pixbuf
Gdk::Pixbuf可以用于从文件系统中装载图片资源，如果是程序中使用的图标之类的，那没问题，因为直到程序结束你才需要释放它。但是你要是反复地加载图片供Gtk::Image显示，那就要小心了，当你用Pixbuf::new(filename)方法生成pixbuf对象，此对象不被VM回收，直到GTK.main返回。测试代码:

100.times do
  pixbuf = Gdk::Pixbuf.new('my_image.jpg')
end
GC.start

观察ruby的内存占用就知道了。

Work around:
如果用Gdk::Pixbuf.new(data, colorspace, has_alpha, ...)方法生成Pixbuf对象，则此pixbuf可以被VM正确回收。这里data是图像的点阵信息，可以用其它库获得，例如可以用Camellia库，或者opencv库。


2) Gtk::Window
由于Ruby/GTK是在GTK库的API上封装ruby的API，GTK有自己的一套对象管理机制，因此Gtk::Window.new生成一个窗口对象时，内部同时注册了GTK的对象。当窗口被destroy时，并没有完全释放资源（可能某个对象的引用计数没有被正确的减一），因此ruby VM无法回收窗口对象，造成内存泄露。测试代码:

class MyWindow < Gtk::Window
  def initialize
    super
    @test = " " * (1024*1024*10)
  end
end

win = MyWindow.new
win.show_all
win.destroy
GC.start

Work Around:
手工释放资源:(

class MyWindow < Gtk::Window
  def initialize
    super
    @test = " " * (1024*1024*10)
    signal_connect("destroy") do
      @test = nil
    end
  end
end

win = MyWindow.new
win.show_all
win.destroy
GC.start

当我们手工告诉VM释放@test，VM正确地回收了@test的资源。但是实际上win对象还是没有完全释放，这个work around只是减轻了内存泄露，并不能完全避免。

以上列出的两个bug我还需要进一步dig Ruby/GTK的source,看看能不能找到根源，如果不能解决只好report到Ruby/GTK项目了。

9月7日新发布的0.17.0版本依然存在此问题，已在ruby1.8.7上测试过。

-----
[好消息，在最新的trunk代码中,r3305已经修复了此bug!在我提交bug-report仅一天之后就得到修复，看来ruby-gnome2的开发活动还是非常活跃:)]