Ruby core dump (1.6.8 on FreeBSD)

ruby-talk
1

I have found a reproducible code snippet which causes a ruby core dump. It
doesn’t affect 1.7.3 and I can’t get it to happen on my linux box. Only ruby
1.6.8 running on FreeBSD 4.7-stable. I am attaching a sample code snippet
and a gdb backtrace. If you need any other info, please let me know.

In case you’re curious about the code snippet, I am working with FastCGI and
found the problem when testing multipart form POST’s. FWIW, if I change
cgi.rb around line 851 where it defines “def body.original_filename” so the
“filename” variable is defined before the eval() block, I no longer get a
core dump.

Thanks,
-Brad

P.S. Please CC me as I’m not subscribed to the ruby-talk list.

Ruby version: ruby 1.6.8 (2002-12-09) [i386-freebsd4]
Backtrace:

#0 0x2817d674 in kill () from /usr/lib/libc.so.4
#1 0x281be19e in abort () from /usr/lib/libc.so.4
#2 0x2807dc6a in rb_bug (fmt=0x280fe0d0 “Segmentation fault”) at error.c:179
#3 0x280da719 in sigsegv (sig=11) at signal.c:393
#4 0xbfbfffac in ?? ()
#5 0x28087f29 in rb_yield (val=135363904) at eval.c:3732
#6 0x280e01df in rb_str_sub_bang (argc=1, argv=0xbfbfc364, str=135363964)
at string.c:1172
#7 0x280e033b in rb_str_sub (argc=1, argv=0xbfbfc364, str=135364224)
at string.c:1207
#8 0x28089627 in call_cfunc (func=0x280e0308 <rb_str_sub>, recv=135364224,
len=-1, argc=1, argv=0xbfbfc364) at eval.c:4279
#9 0x28089c26 in rb_call0 (klass=134720684, recv=135364224, id=4233, argc=1,
argv=0xbfbfc364, body=0x807a3c4, nosuper=1) at eval.c:4416
#10 0x2808a494 in rb_call (klass=134720684, recv=135364224, mid=4233, argc=1,
argv=0xbfbfc364, scope=0) at eval.c:4640
#11 0x28084b08 in rb_eval (self=135367024, n=0x805d33c) at eval.c:2572
#12 0x28083a08 in rb_eval (self=135367024, n=0x805d0f8) at eval.c:2304
#13 0x28085523 in rb_eval (self=135367024, n=0x805d0e4) at eval.c:2724
#14 0x28082f87 in rb_eval (self=135367024, n=0x805e598) at eval.c:2053
#15 0x280837bf in rb_eval (self=135367024, n=0x805c450) at eval.c:2267
#16 0x28082f87 in rb_eval (self=135367024, n=0x805f218) at eval.c:2053
#17 0x2808a05b in rb_call0 (klass=135366944, recv=135367024, id=9209, argc=0,
argv=0xbfbfd63c, body=0x805f218, nosuper=0) at eval.c:4547
#18 0x2808a494 in rb_call (klass=135366944, recv=135367024, mid=9209, argc=2,
argv=0xbfbfd634, scope=1) at eval.c:4640
#19 0x28084b08 in rb_eval (self=135367024, n=0x805b578) at eval.c:2572
#20 0x280855f7 in rb_eval (self=135367024, n=0x805aed4) at eval.c:2744
#21 0x28082f87 in rb_eval (self=135367024, n=0x805ad30) at eval.c:2053
#22 0x2808a05b in rb_call0 (klass=135366944, recv=135367024, id=9321, argc=0,
argv=0x0, body=0x805ad30, nosuper=0) at eval.c:4547
#23 0x2808a494 in rb_call (klass=135366944, recv=135367024, mid=9321, argc=0,
argv=0x0, scope=1) at eval.c:4640
#24 0x28084b08 in rb_eval (self=135367024, n=0x81247d4) at eval.c:2572
#25 0x28082f87 in rb_eval (self=135367024, n=0x8124234) at eval.c:2053
#26 0x28082f87 in rb_eval (self=135367024, n=0x8124b30) at eval.c:2053
#27 0x2808a05b in rb_call0 (klass=135409004, recv=135367024, id=2865, argc=0,
argv=0x0, body=0x8124b30, nosuper=0) at eval.c:4547
#28 0x2808a494 in rb_call (klass=135409004, recv=135367024, mid=2865, argc=0,
argv=0x0, scope=1) at eval.c:4640
#29 0x2808a7a5 in rb_funcall2 (recv=135367024, mid=2865, argc=0, argv=0x0)
at eval.c:4724
#30 0x2808cc96 in rb_obj_call_init (obj=135367024, argc=0, argv=0x0)
at eval.c:5722
#31 0x2808cd0c in rb_class_new_instance (argc=0, argv=0x0, klass=135409004)
#32 0x28089627 in call_cfunc (func=0x2808ccb0 <rb_class_new_instance>,
recv=135409004, len=-1, argc=0, argv=0x0) at eval.c:4279
#33 0x28089c26 in rb_call0 (klass=134728944, recv=135409004, id=3177, argc=0,
argv=0x0, body=0x807bddc, nosuper=1) at eval.c:4416
#34 0x2808a494 in rb_call (klass=134728944, recv=135409004, mid=3177, argc=0,
argv=0x0, scope=0) at eval.c:4640
#35 0x28084b08 in rb_eval (self=134724824, n=0x806eb8c) at eval.c:2572
#36 0x2808558f in rb_eval (self=134724824, n=0x806ec04) at eval.c:2734
#37 0x28087c77 in rb_yield_0 (val=3, self=134724824, klass=0, acheck=0)
at eval.c:3644
#38 0x28087f29 in rb_yield (val=3) at eval.c:3732
#39 0x280abcc6 in fix_dotimes (num=5) at numeric.c:1535
#40 0x28089635 in call_cfunc (func=0x280abc98 <fix_dotimes>, recv=5, len=0,
argc=0, argv=0x0) at eval.c:4282
#41 0x28089c26 in rb_call0 (klass=134707504, recv=5, id=5625, argc=0,
argv=0x0, body=0x8077390, nosuper=1) at eval.c:4416
#42 0x2808a494 in rb_call (klass=134707504, recv=5, mid=5625, argc=0,
argv=0x0, scope=0) at eval.c:4640
#43 0x28084b08 in rb_eval (self=134724824, n=0x806ef24) at eval.c:2572
#44 0x28083a08 in rb_eval (self=134724824, n=0x806f474) at eval.c:2304
#45 0x280808bf in eval_node (self=134724824, node=0x806f474) at eval.c:1085
#46 0x28080d8a in ruby_run () at eval.c:1230
#47 0x80485ca in main (argc=2, argv=0xbfbffbb0, envp=0xbfbffbbc) at main.c:50
#48 0x8048509 in _start ()

expose-bug.rb.gz (535 Bytes)

2

I have found a reproducible code snippet which causes a ruby core dump.

This is the old bug described in [ruby-talk:40979]

It's effectively fixed in 1.7.*

cgi.rb around line 851 where it defines "def body.original_filename" so the
"filename" variable is defined before the eval() block, I no longer get a
core dump.

This is probably the right fix.

Guy Decoux

3

I have found a reproducible code snippet which causes a ruby core dump.

This is the old bug described in [ruby-talk:40979]

It’s effectively fixed in 1.7.*

Thanks for the reply. Is this bug not fixed in 1.6 ? What is the recommended
ruby version for production environments? If 1.6 is still recommended as the
most stable version, should cgi.rb be patched to not cause the core dump?
I’d rather not maintain local diffs if I can help it.

Thanks,
-Brad

···

On Sunday 15 December 2002 6:09 am, ts wrote:

Guy Decoux

4

Hi,

···

At Tue, 17 Dec 2002 06:10:43 +0900, Brad Hilton wrote:

I have found a reproducible code snippet which causes a ruby core dump.

This is the old bug described in [ruby-talk:40979]

It’s effectively fixed in 1.7.*

Thanks for the reply. Is this bug not fixed in 1.6 ? What is the recommended
ruby version for production environments? If 1.6 is still recommended as the
most stable version, should cgi.rb be patched to not cause the core dump?
I’d rather not maintain local diffs if I can help it.

Fixed in 1.6.8-preview4, I hope.

–
Nobu Nakada

5

I have subclassed FXTreeItem (MyTreeItem) and built a
tree out of it. That works fine.

However, when ‘connecting’ a SEL_COMMAND sent to the
tree to a method, the item that is sent is an
FXTreeItem, and not a MyTreeItem. Is this the
intended behaviour?

A hackish method of fixing this would be to search the
tree for the MyTreeItem with the same reference
(hmm… actually I really don’t know if I CAN do
that…)

Jason

6

Jason Persampieri wrote:

I have subclassed FXTreeItem (MyTreeItem) and built a
tree out of it. That works fine.

However, when ‘connecting’ a SEL_COMMAND sent to the
tree to a method, the item that is sent is an
FXTreeItem, and not a MyTreeItem. Is this the
intended behaviour?

No, you should get a reference to the original MyTreeItem object(s).
This sounds like a bug that has already been fixed for the (pending)
FXRuby-1.0.17 release; if you want to send me a test case to
double-check, I’d be glad to confirm that it’s doing the right thing
before the official 1.0.17 release.

7

Ahhh… always one step ahead of me, aren’t ya?

Here’s a test case

require ‘fox’
include Fox

class MyTreeItem < FXTreeItem
end

class MyMainWindow < FXMainWindow
def initialize(app)
super(app, “Era - The Kush Build System”, nil,
nil, DECOR_ALL, 0, 0, 200, 200)
tree = FXTreeList.new(self, 0, nil, 0,
LAYOUT_FILL_X|LAYOUT_FILL_Y)
tree.addItemLast(nil, MyTreeItem.new(“NewItem”))
tree.connect(SEL_COMMAND) {|sender, sel, item|
puts item.class.to_s}
end
end

theApp = FXApp.new
theApp.init(ARGV)

myWindow = MyMainWindow.new(theApp)
theApp.create
myWindow.show(PLACEMENT_SCREEN)
theApp.run

···

— Lyle Johnson lyle@users.sourceforge.net wrote:

Jason Persampieri wrote:

I have subclassed FXTreeItem (MyTreeItem) and
built a
tree out of it. That works fine.

However, when ‘connecting’ a SEL_COMMAND sent to
the
tree to a method, the item that is sent is an
FXTreeItem, and not a MyTreeItem. Is this the
intended behaviour?

No, you should get a reference to the original
MyTreeItem object(s).
This sounds like a bug that has already been fixed
for the (pending)
FXRuby-1.0.17 release; if you want to send me a test
case to
double-check, I’d be glad to confirm that it’s doing
the right thing
before the official 1.0.17 release.

8

not to mention… when you run this sample with Ruby
1.7.3 (but not with 1.6.7), it crashes as soon as you
click on the item, then move the mouse…

bug.rb:22:in getItemAt': undefined method getWidth’
for nil (NoMethodError)
from bug.rb:22:in `run’
from bug.rb:22

Jason

hehe… this is what I get for using a programming
language in development with a window manager in
development :wink:

···

— Jason Persampieri jason@persampieri.net wrote:

Ahhh… always one step ahead of me, aren’t ya?

Here’s a test case

require ‘fox’
include Fox

class MyTreeItem < FXTreeItem
end

class MyMainWindow < FXMainWindow
def initialize(app)
super(app, “Era - The Kush Build System”, nil,
nil, DECOR_ALL, 0, 0, 200, 200)
tree = FXTreeList.new(self, 0, nil, 0,
LAYOUT_FILL_X|LAYOUT_FILL_Y)
tree.addItemLast(nil, MyTreeItem.new(“NewItem”))
tree.connect(SEL_COMMAND) {|sender, sel, item|
puts item.class.to_s}
end
end

theApp = FXApp.new
theApp.init(ARGV)

myWindow = MyMainWindow.new(theApp)
theApp.create
myWindow.show(PLACEMENT_SCREEN)
theApp.run

— Lyle Johnson lyle@users.sourceforge.net wrote:

Jason Persampieri wrote:

I have subclassed FXTreeItem (MyTreeItem) and
built a
tree out of it. That works fine.

However, when ‘connecting’ a SEL_COMMAND sent to
the
tree to a method, the item that is sent is an
FXTreeItem, and not a MyTreeItem. Is this the
intended behaviour?

No, you should get a reference to the original
MyTreeItem object(s).
This sounds like a bug that has already been
fixed
for the (pending)
FXRuby-1.0.17 release; if you want to send me a
test
case to
double-check, I’d be glad to confirm that it’s
doing
the right thing
before the official 1.0.17 release.

9

Jason Persampieri wrote:

not to mention… when you run this sample with Ruby
1.7.3 (but not with 1.6.7), it crashes as soon as you
click on the item, then move the mouse…

bug.rb:22:in getItemAt': undefined method getWidth’
for nil (NoMethodError)
from bug.rb:22:in `run’
from bug.rb:22

Yes, all of these problems (well, they’re all symptoms of the same
problem) have been addressed for FXRuby-1.0.17. I hope to be able to
wrap that one up soon and make an official release later this week.

hehe… this is what I get for using a programming
language in development with a window manager in
development :wink:

Welcome to the bleeding egde :wink:

10

Hmmm… these problems don’t seem to go away with the
new version (ruby 1.7.3). fxversion returns 1,0,26…
is that what it’s supposed to be?

Jason

···

— Lyle Johnson lyle@users.sourceforge.net wrote:

Jason Persampieri wrote:

not to mention… when you run this sample with
Ruby
1.7.3 (but not with 1.6.7), it crashes as soon as
you
click on the item, then move the mouse…

bug.rb:22:in getItemAt': undefined method getWidth’
for nil (NoMethodError)
from bug.rb:22:in `run’
from bug.rb:22

Yes, all of these problems (well, they’re all
symptoms of the same
problem) have been addressed for FXRuby-1.0.17. I
hope to be able to
wrap that one up soon and make an official release
later this week.

hehe… this is what I get for using a programming
language in development with a window manager in
development :wink:

Welcome to the bleeding egde :wink:

11

Jason Persampieri wrote:

Hmmm… these problems don’t seem to go away with the
new version (ruby 1.7.3). fxversion returns 1,0,26…
is that what it’s supposed to be?

Fox::fxversion just returns the version number of the FOX library that
FXRuby is using. It doesn’t give any indication of which FXRuby release
you’re using (hmmm… another thing to add to my list).

The two Windows installers I uploaded to SourceForge this morning (for
FXRuby-1.0.17) were built against fox-1.0.28, so they should both return
[1,0,28]. If they don’t, you may have installed them to the wrong directory.