fxruby users - Feb 2005 - Big tables still segfault with fxruby-1.2.4

I''ve installed the latest fxruby. (Fox::fxrubyversion() reports 1.2.4.)
But my installation of fxruby still crashes with a segmentation fault 
when refilling FXTables with large data sets.

My original report was attached to bug #1445. I''m including the test 
code below. The platform is Windows XP, and Ruby is from the one-click 
installer version 182-14 Final.

I''d appreciate it if others could run this code to see if the segfault 
shows up on other machines or just mine.

David Peoples

-------------------------------------------------------------------------

require "fox12"
include Fox

class TestWindow < FXMainWindow

   TABLE_SIZE = 10_000

   def initialize(app)
     super(app, "MyTest", nil, nil, DECOR_ALL, 0, 0, 600, 400, 0, 0)
     mainFrame = FXVerticalFrame.new(self, LAYOUT_FILL_X|LAYOUT_FILL_Y)
     @table = FXTable.new(mainFrame, nil, 0, LAYOUT_FILL_X|LAYOUT_FILL_Y)
     goButton = FXButton.new(mainFrame, " Go method 1")
     goButton.connect(SEL_COMMAND) { fillTable }
     goButton2 = FXButton.new(mainFrame, " Go method 2")
     goButton2.connect(SEL_COMMAND) { fillTable2 }
   end

   # fails after 2 to 15-20 iterations
   def fillTable
     @table.setTableSize(TABLE_SIZE, 1)
     (0...TABLE_SIZE).each do |r|
       @table.setItemText(r, 0, "#{r}")
     end
     @table.setFocus
   end

   # seems to require more iterations, but still fails
   def fillTable2
     @table.setTableSize(0, 1)
     (0...TABLE_SIZE).each do |r|
       @table.insertRows(r)
       @table.setItemText(r, 0, "#{r}")
     end
     @table.setFocus
   end

   def create
     super
     show(PLACEMENT_SCREEN)
   end

end

def runme
   application = FXApp.new("MyTest", "FoxTest")
   TestWindow.new(application)
   application.create
   application.run
end

runme

-------------------------------------------------------------------------

-- 
David Peoples  davidp@touringcyclist.com  http://www.touringcyclist.com
The Touring Cyclist, 11816 St. Charles Rock Road, Bridgeton MO 63044
tel: 314-739-4648  fax: 314-739-4972

On Fri, 25 Feb 2005 07:47:21 -0600, David Peoples
<davidp@touringcyclist.com> wrote :
> I''ve installed the latest fxruby. (Fox::fxrubyversion() reports
1.2.4.)
> But my installation of fxruby still crashes with a segmentation fault 
> when refilling FXTables with large data sets.
OK. For what it''s worth, I *did* run your test program on my Mac OS X
box
and was able to click the "Go method 1" button about 40 times without
crashing the program. I will take another look at it this weekend (on a
Windows box) and see if I can reproduce the problem there.

lyle@knology.net wrote:
> On Fri, 25 Feb 2005 07:47:21 -0600, David Peoples
> <davidp@touringcyclist.com> wrote :
> 
> 
>>I''ve installed the latest fxruby. (Fox::fxrubyversion() reports
1.2.4.)
>>But my installation of fxruby still crashes with a segmentation fault 
>>when refilling FXTables with large data sets.
> 
> 
> OK. For what it''s worth, I *did* run your test program on my Mac
OS X box
> and was able to click the "Go method 1" button about 40 times
without
> crashing the program. I will take another look at it this weekend (on a
> Windows box) and see if I can reproduce the problem there.
I assumed you had run my test or something like it and the code had 
passed, and there was just something different about the platform
you''re
testing on from mine. So it looks like it might come down to some 
obscure Windows bug? Fancy that. <g> I hope you can find it.

I keep worrying that this will turn out to be some display driver 
problem, like the bad old Win95 days, where it shows up on just a 
minority of the systems out there. I really need to bring Linux up to 
date on this machine and start developing there. Maybe that will be *my* 
project for this weekend.

David

-- 
David Peoples  davidp@touringcyclist.com
The Touring Cyclist  http://www.touringcyclist.com
11816 St. Charles Rock Road, Bridgeton, MO 63044
tel: 314-739-4648  fax: 314-739-4972

On Fri, 25 Feb 2005 11:02:56 -0600, David Peoples
<davidp@touringcyclist.com> wrote :
> I assumed you had run my test or something like it and the code had 
> passed, and there was just something different about the platform
you''re
> testing on from mine. So it looks like it might come down to some 
> obscure Windows bug? Fancy that. <g> I hope you can find it.
Well, just because we''re (so far) only seeing the crash on Windows
doesn''t
mean that it''s a bug in Windows. It is quite possibly a bug in the
FXRuby
code that just keeps its mouth shut when running under Mac OS X. ;)

But either way, I consider this extremely high priority and want to get it
fixed ASAP.
> I keep worrying that this will turn out to be some display driver 
> problem, like the bad old Win95 days, where it shows up on just a 
> minority of the systems out there. I really need to bring Linux up to 
> date on this machine and start developing there. Maybe that will be *my* 
> project for this weekend.
I really, really don''t think it''s a display driver problem
(although I used
to do a lot of nightmarish customer support back in those bad old days). Now
that Jamey (for one) has independently confirmed it on his Windows box that
makes it less likely that it''s something like that. Of course,
I''m not going
to discourage you from switching (or is it switching back?) to Linux either. ;)

David Peoples wrote:
> I''ve installed the latest fxruby. (Fox::fxrubyversion() reports
1.2.4.)
> But my installation of fxruby still crashes with a segmentation fault 
> when refilling FXTables with large data sets.
> 
> My original report was attached to bug #1445. I''m including the
test
> code below. The platform is Windows XP, and Ruby is from the one-click 
> installer version 182-14 Final.
> 
> I''d appreciate it if others could run this code to see if the
segfault
> shows up on other machines or just mine.
Crashes repeatably within 10 clicks on linux:

$ ruby -v
ruby 1.8.2 (2004-12-25) [i686-linux]
$ uname -a
Linux tercel.path.berkeley.edu 2.6.10 #1 Fri Jan 7 01:41:12 PST 2005 
i686 Pentium III (Coppermine) unknown GNU/Linux

...and FXRuby is the new 1.2.24.


Adding "GC.disable" at the top lets me click about 40 times, and no 
crash. (Had to stop there because it was gobbling VM.)

Btw, I''ve been seeing, in my own code, a table-filling related, 
GC-dependent bug as well. I hope it''s the same as this bug!

I''ll try to post a small test case.

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".

$ ruby fxbug2.rb
fxbug2.rb:25: [BUG] rb_gc_mark(): unknown data type 0x30(0x82255f0) non 
object
ruby 1.8.2 (2004-12-25) [i686-linux]

zsh: abort      ruby fxbug2.rb


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 may be able to use that in my own case...


------------------------
require "fox12"
include Fox

#GC.disable

class TestWindow < FXMainWindow

   TABLE_SIZE = 10 # <--- added

   def initialize(app)
     super(app, "MyTest", nil, nil, DECOR_ALL, 0, 0, 600, 400, 0, 0)
     mainFrame = FXVerticalFrame.new(self, LAYOUT_FILL_X|LAYOUT_FILL_Y)
     @table = FXTable.new(mainFrame, nil, 0, LAYOUT_FILL_X|LAYOUT_FILL_Y)
     goButton = FXButton.new(mainFrame, " Go method 1")
     goButton.connect(SEL_COMMAND) { fillTable }
     goButton2 = FXButton.new(mainFrame, " Go method 2")
     goButton2.connect(SEL_COMMAND) { fillTable2 }
   end

   # fails after 2 to 15-20 iterations
   def fillTable
     @table.setTableSize(TABLE_SIZE, 1)
     (0...TABLE_SIZE).each do |r|
       @table.setItemText(r, 0, "#{r}")
       GC.start # <--- added
     end
     @table.setFocus
     GC.start # <--- added
   end

   # seems to require more iterations, but still fails
   def fillTable2
     @table.setTableSize(0, 1)
     (0...TABLE_SIZE).each do |r|
       @table.insertRows(r)
       @table.setItemText(r, 0, "#{r}")
     end
     @table.setFocus
   end

   def create
     super
     show(PLACEMENT_SCREEN)
   end

end

def runme
   application = FXApp.new("MyTest", "FoxTest")
   TestWindow.new(application)
   application.create
   application.run
end

runme

Joel VanderWerf wrote:
>
> Btw, I''ve been seeing, in my own code, a table-filling related, 
> GC-dependent bug as well. I hope it''s the same as this bug!
>
You know, now that I think about it, I saw this problem a few months ago 
with an app that I wrote for work.  I installed the app on about 15 pcs 
at work.  One guy was really zealous about using it.  He kept adding new 
records to the database which meant he was constantly displaying an 
FXTable, going to an edit screen to add a new record, and then being 
taken back to a new rendition of the FXTable.

I remember he called me over to tell me that after adding about 20-25 
records the app crashed.  I tested it a little and found that, if I 
constantly opened and closed a window that had an FXTable on it, the 
memory used gradually increased and eventually the program would crash.  
Because I had some icons on the same screen as the FXTable, I always 
assumed that it was because I was not correctly destroying the icon 
resources when I closed the window, but now that I see David''s test 
code, I realize that that was probably not the case.

Hope this helps!

Jamey Cribbs

Confidentiality Notice: This email message, including any attachments, is for
the sole use of the intended recipient(s) and may contain confidential and/or
privileged information. If you are not the intended recipient(s), you are hereby
notified that any dissemination, unauthorized review, use, disclosure or
distribution of this email and any materials contained in any attachments is
prohibited. If you receive this message in error, or are not the intended
recipient(s), please immediately notify the sender by email and destroy all
copies of the original message, including attachments.

Joel VanderWerf wrote:

...
> Crashes repeatably within 10 clicks on linux:
> 
> $ ruby -v
> ruby 1.8.2 (2004-12-25) [i686-linux]
> $ uname -a
> Linux tercel.path.berkeley.edu 2.6.10 #1 Fri Jan 7 01:41:12 PST 2005 
> i686 Pentium III (Coppermine) unknown GNU/Linux
> 
> ...and FXRuby is the new 1.2.24.
...

So now the score is OS X 1, Linux 0, Windows 0. Those Mac fanatics are 
going to have a field day with this one! <g>

David


-- 
David Peoples  davidp@touringcyclist.com
The Touring Cyclist  http://www.touringcyclist.com
11816 St. Charles Rock Road, Bridgeton, MO 63044
tel: 314-739-4648  fax: 314-739-4972

On Fri, 25 Feb 2005 10:39:21 -0800, Joel VanderWerf
<vjoel@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".
OK.
> 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.

P.S.

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

Joel VanderWerf wrote:
> Btw, I''ve been seeing, in my own code, a table-filling related, 
> GC-dependent bug as well. I hope it''s the same as this bug!
I''m pretty sure it _is_ the same bug. For now, I am being careful never
to let go of any table items (calling #setTableSize once), and no 
crashes yet.