[BUG] object allocation during garbage collection phase

[nsasherr]

Binary package hint: ruby1.8

This error occurs within a GTK application, so this might be the cause of the error ( as suggested here: http://www.ruby-forum.com/topic/168922 ), but the error locations provided do not seem to line up with any GTK interaction, so I am hesitant to make that assumption.

The error:

[BUG] object allocation during garbage collection phase
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

appears when executing code repeatably and consistantly.

This post for the same bug appearing with wxWidgets in Ruby also seems to have some information:
http://www.ruby-forum.com/topic/161876

I'm not sure what specific information would be helpful in this case, but I'll try and post anything that you think would be of use.

[Niklas Hofer (niklas+launchpad)]

The same happens when starting a rails application with rails 2.1.0 installed from gems before the dist-upgrade from hardy to intrepid.

[nsasherr (nsasherr)]

Thanks Niklas, so if what was suggested here ( http://www.ruby-forum.com/topic/161876 )is true, then it sounds like an issue with new GC API changes and old versions of various libraries.

[Niklas Hofer (niklas+launchpad)]

Yes Chiron, it seems so. I uninstalled all gems one by one and reinstalled those I needed. libxml-ruby was the one causing troubles.

[Lucas Nussbaum (lucas)]

that was a libxml-ruby bug, that has been fixed in 0.5.2.0-3+lenny1 (on the Debian side). I'm not sure it's worth backporting the patch to hardy....

[nsasherr (nsasherr)]

I am still having this issue in ruby programmes that do not pull in libxml, so I think that it is in at least one other ruby library. I suspect that it is in cairo or glade, since those are the two libraries that are being used at the time of the crash. Should this bug be reopened, or a new one created?

[Lucas Nussbaum (lucas)]

On which version of Ubuntu ?

[nsasherr (nsasherr)]

Intrepid, up to data, with backports.

I'm fairly certain its in cairo somewhere - I've narrowed the issue down to a ruby class extending a Gtk::Drawable, using cairo to draw with it. The drawing is fairly intensive, so it draws to an ImageSurface before drawing that to the control's surface, in case that detail makes any difference.

[Lucas Nussbaum (lucas)]

On 08/03/09 at 23:50 -0000, Chiron wrote:
> Intrepid, up to data, with backports.
>
> I'm fairly certain its in cairo somewhere - I've narrowed the issue down
> to a ruby class extending a Gtk::Drawable, using cairo to draw with it.
> The drawing is fairly intensive, so it draws to an ImageSurface before
> drawing that to the control's surface, in case that detail makes any
> difference.

Debian bug #487204 seems to be what we are looking for.

The fix is in libcairo-ruby version 1.5.1-1+lenny1. (available in
lenny), which is already available in intrepid according to
https://launchpad.net/ubuntu/+source/libcairo-ruby

Are you sure you are up-to-date?
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[nsasherr (nsasherr)]

libcairo-ruby1.8 version is 1.5.1-1+lenny1

[Lucas Nussbaum (lucas)]

Mmmh.

In the debian bug ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487204 ), the following test case was provided:

<--------->
require 'cairo'
require 'stringio'

i = 0;
while true
  output = StringIO.new
  surface = Cairo::PDFSurface.new(output, 100, 100)
  context = Cairo::Context.new(surface)
  i += 1;
  puts "***************** #{i} *********" if i%100 == 0;
end
<--------->

Could you check if it crashes?

If not, could you try to write a testcase for your problem?

It's possible that the fix for the debian bug was only partial.

Something else to test would be the version of libcairo-ruby in jaunty (i.e the newer version).

[nsasherr (nsasherr)]

That doesn't crash in irb until I ^C the loop and type in 'exit'

Running this as a script with ruby does make it crash, though:

<--------->
require 'cairo'
require 'stringio'

i = 0;
1000.times do
 output = StringIO.new
 surface = Cairo::PDFSurface.new(output, 100, 100)
 context = Cairo::Context.new(surface)
 i += 1;
 puts "***************** #{i} *********" if i%100 == 0;
end
<--------->
results in:
testcase.rb:5: [BUG] object allocation during garbage collection phase
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]

where line 5 is the "1000.times do" command

[nsasherr (nsasherr)]

I should add that in the test case that I have provided, there is a lower bound (85 for me) below which the test case does not cause an error.

[nsasherr (nsasherr)]

installing libcairo-ruby1.8_1.6.3-1_i386.deb for sid from packages.debian.org didn't fix the problem

[Lucas Nussbaum (lucas)]

On 14/03/09 at 19:48 -0000, Chiron wrote:
> That doesn't crash in irb until I ^C the loop and type in 'exit'
>
> Running this as a script with ruby does make it crash, though:
>
> <--------->
> require 'cairo'
> require 'stringio'
>
> i = 0;
> 1000.times do
> output = StringIO.new
> surface = Cairo::PDFSurface.new(output, 100, 100)
> context = Cairo::Context.new(surface)
> i += 1;
> puts "***************** #{i} *********" if i%100 == 0;
> end
> <--------->
> results in:
> testcase.rb:5: [BUG] object allocation during garbage collection phase
> ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
>
> where line 5 is the "1000.times do" command

AH! thank you. I can see it now.

Will investigate.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |

[nsasherr (nsasherr)]

I appear to have been mistaken about 1.6.3 not working. It *sort of* works.

By that, I mean that the test case that I provided you with now works. My programme still doesn't, though.

I'm working on extracting a piece of the programme for use as another test case for you.

[nsasherr (nsasherr)]

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

[Lucas Nussbaum (lucas)]

I reported this as a different debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519786

[nsasherr (nsasherr)]

Thanks. For the cairo bug, would the solution then be to move version 1.6.3 of libcairo-ruby into 8.10 since it seems to fix the earlier test case?

[Lucas Nussbaum (lucas)]

On 17/03/09 at 18:33 -0000, Chiron wrote:
> Thanks. For the cairo bug, would the solution then be to move version
> 1.6.3 of libcairo-ruby into 8.10 since it seems to fix the earlier test
> case?

Yes, that could be a solution. The other solution is to fix it in Debian
lenny, and use the fixed version in 8.10. I don't think that Ubuntu
policies would allow to use 1.6.3 in 8.10.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |