[fxruby-users] Big tables still segfault with fxruby-1.2.4

lyle at knology.net lyle at knology.net
Fri Feb 25 15:33:29 EST 2005

On Fri, 25 Feb 2005 10:39:21 -0800, Joel VanderWerf
<vjoel at path.berkeley.edu> wrote :

> By putting some GC.start lines in David's original code, the problem 
> comes up much faster. With just 10 rows, it happens in 2 clicks on 
> button 1. Changes marked with " # <--- added".


> Another observation: moving the setTableSize call into initialize seems 
> to avoid the problem. So it appears that as long as you never discard 
> any items, it's ok.

I was already thinking about that possibility (since I'm still at work and
can't actually hack on this yet).

The problem that I *did* fix has to do with making sure that when an FXTable
is destroyed, we "neutralize" all of the Ruby objects representing its table
items so that they don't wreak any havoc before they eventually get GC'd.
But there are some other "destructive" FXTable methods -- like
setTableSize(), for instance -- that can also kill off C++ FXTableItem
objects and leave behind Ruby peers that need to be similarly neutralized.

Once I get things set up to test under Windows, and first confirm that I can
reproduce David's crash, this seems like a good place to start. With some
luck, maybe I can get a bug fix out release over the weekend.


Of course, Saturday is my 11th wedding anniversary. My wife may have
different plans for my weekend than working on FXRuby. ;)

More information about the fxruby-users mailing list