[ruby-gnome2] general memory problems with ruby-gnome2?

Hi all.

This is not a message about a concrete error. I need your advice in
order to explore memory problems with an application using ruby1.8
and ruby-gnome2 in Linux Debian Sid.

My application is relatively complex. It generates dinamic windows
form represnting data in postgres database. Each window has a
notebook with various pages, and each page has a treeview
representing detail of data.

So, in diary work, program creates and destroys windows continually.

When I worked with ruby-gnome1, there was no memory problems and
program was speedy. But now, with same estructure of data
presentation and using ruby-gnome2, memory use grows without limit
until machine begins to use virtual memory in great amounts, slowing
work.

I destroy each window properly when it is closed, but don't know if
that is enought. Might I do anything more in order to reduce memory
usage?

Thanks for your advice. Greets.

               David

David,

Without looking at the code, there are a couple of things I might recommend:

First, as a simple debugging tool, add a log of the GObjects left in
memory after certain major operations with something like the
following:
  if DEBUG
    GC.start
    ObjectSpace.each_object(GLib::Object) {|o|
      STDERR.puts "#{o.inspect} :: #{o.ref_count}
    }
  end

If that list just keeps growing each time, even though you're trying
to free any old window handles, then the refcounts on the widgets
you're creating aren't getting to zero. I'd look for any persistent
(as in lasts as long as the program runs) datastructure (like a hash
of window references, or instance variables of a wrapper class) that
could be holding on to references.

Otherwise, if you just can't seem to track down the refs or it turns
out that the Ruby-GNOME2 bindings aren't letting them get GC'd
properly, then you might want to try re-using window and widget
handles, rather than destroying and recreating them each time.
Top-level windows, TreeModel/View/Store instances, etc., are probably
"heavy" enough to be worth keeping around and re-populating with new
child widgets and data as needed.

Hope that helps,

Lennon

···

On Wed, 30 Jun 2004 18:02:57 +0900, David Espada <davincisinspam@escomposlinux.org> wrote:

Hi all.

This is not a message about a concrete error. I need your advice in
order to explore memory problems with an application using ruby1.8
and ruby-gnome2 in Linux Debian Sid.

My application is relatively complex. It generates dinamic windows
form represnting data in postgres database. Each window has a
notebook with various pages, and each page has a treeview
representing detail of data.

So, in diary work, program creates and destroys windows continually.

When I worked with ruby-gnome1, there was no memory problems and
program was speedy. But now, with same estructure of data
presentation and using ruby-gnome2, memory use grows without limit
until machine begins to use virtual memory in great amounts, slowing
work.

I destroy each window properly when it is closed, but don't know if
that is enought. Might I do anything more in order to reduce memory
usage?

Thanks for your advice. Greets.

                                                        David

Good!

I have probed many things. Now I Know where is the problem (main
problem, at least). When I use Gtk::NoteBook in a data window, there
is no parent for the pages of that. So, when I destroy window, pages
with ALL their contents survive in memory until application hangs.

If I do:

   signal_connect('destroy') do
    children.each do |c|
      c.destroy
    end
  end

in NoteBook constructor, problem dissapears and all memory frees
normally (or so I think).

Thanks for your help with debugging method :slight_smile:

Greets.

               David

···

El miércoles 30 de junio, Lennon Day-Reynolds escribió:

First, as a simple debugging tool, add a log of the GObjects left in
memory after certain major operations with something like the
following:
  if DEBUG
    GC.start
    ObjectSpace.each_object(GLib::Object) {|o|
      STDERR.puts "#{o.inspect} :: #{o.ref_count}
    }
  end