[ruby-core:17393] URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk

3 views
Skip to first unread message

Igal Koshevoy

unread,
Jun 24, 2008, 5:39:23 AM6/24/08
to ruby...@ruby-lang.org
All currently available versions of MRI Ruby are either vulnerable to
attacks, failing with segmentation faults, or
change the API in ways that make it impossible to run critical Ruby
libraries such as Rails 2.0 and RSpec.

There are currently two unofficial patches submitted by ruby-talk
members that seem to fix these problems:
* http://www.ruby-forum.com/topic/157034#693292
* http://www.ruby-forum.com/topic/157034#693303

One is a backport of fixes to 1.8.6p111 by Stanislav Sedov and Hongli
Lai. The other is a fix to 1.8.6p230 by Smartleaf
which reverts a recent patch that's causing segmentation faults.

I've personally confirmed that both of these work as well as the stock
1.8.6p111 in running the Rails 2.0, RSpec 1.1.4,
and RubySpec test suites. However, I do not understand the C patches
well enough to be able to help with them myself.

Please review these patches and join in the discussion at ruby-talk or
the online thread
at http://www.ruby-forum.com/topic/157034

Thank you!

-igal

Message has been deleted

Urabe Shyouhei

unread,
Jun 28, 2008, 6:28:09 AM6/28/08
to ruby...@ruby-lang.org
Sorry for a late reply but I think I've fixed this issue. Can someone
please try the latest ruby_1_8_6 branch?

Igal Koshevoy

unread,
Jun 28, 2008, 8:27:43 AM6/28/08
to ruby...@ruby-lang.org
Urabe Shyouhei wrote:
> Sorry for a late reply but I think I've fixed this issue. Can someone
> please try the latest ruby_1_8_6 branch?
>
I'm delighted to hear from you!

I've checked out the latest source code and ran the test suites of
RubySpec, Rails and RSpec on it. The segfaults are gone and I'm able to
run Rails applications again. However, many tests are failing in a way
that indicates there are either bugs or changes in the API which cause
p238 to behave differently than p111.

I've updated the RedMine ticket
[http://redmine.ruby-lang.org/issues/show/199] and uploaded the
following files:
1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
the test suites
2. logs.tar.gz -- The test suite logs for the various programs

In the logs, the "p111.log" files were created with Ubuntu 8.04's
patched Ruby 1.8.6p111, while the "17630.log" files were created with
SVN r17630. The best way to work with these log files is to use a modern
diff program like "gvimdiff" or "meld" which can detect intra-line
changes (a few characters changed within a line), and visually compare
them side-by-side. Note that a number of tests fail on both, this is
unfortunately normal. What's important is that the same tests pass and
fail on both versions. I'll try to make sense of the changes and errors
after I get some sleep.

Because the lastest SVN version seems to introduce API changes, trying
to fix it may be time consuming and stressful.

I urge you to consider reviewing the submitted unofficial patches and
make a new release based on a well-known stable version of the code,
such as p111 or p114.

Thank you!

-igal

Urabe Shyouhei

unread,
Jun 28, 2008, 2:36:10 PM6/28/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> Because the lastest SVN version seems to introduce API changes, trying
> to fix it may be time consuming and stressful.
>
> I urge you to consider reviewing the submitted unofficial patches and
> make a new release based on a well-known stable version of the code,
> such as p111 or p114.

No, I don't like that menu. Please take a look at the ChangeLog. All
modifications applied to 1.8.6 are bugfixes. You may think p114 was
stable enough, but it wasn't than the current one. I apologize for some
of them being incomplete, but simply reverting them won't make you happy.

Igal Koshevoy

unread,
Jun 28, 2008, 8:09:09 PM6/28/08
to ruby...@ruby-lang.org
To: Urabe Shyouhei

Thank you for the explanation.

We are grateful for the bug fixes, but this version seems to change the
API. If the tests fail and API changes, then we can't deploy this
version to our users because their applications won't work.

I respect your concerns and recognize that both options I listed are
unpleasant, but urgency may require a compromised choice. Creating a
backport against p111 or p114 using some of the submitted patches as
guidance will make it possible to create a fully-compatible official
solution within hours. In contrast, figuring out how to make the latest
SVN version compatible can take days to weeks.

I realize that a backport using an older version may seem distasteful,
but most people are using p36, p111, and p114 with selected patches.
These older versions may have issues, but nothing that's so noticeable
that it prevents them from being used, unlike the new versions.

For the sake of protecting Ruby's good image, I believe it's necessary
to ship an *official* version that's compatible and addresses these
vulnerabilities as soon as possible. After that's shipped, resolving the
matter with the API changes in the current code will likely be a
priority. If there's anything that we in the Ruby community can help you
with, please ask. :)


To: All

If anyone can lend a, check out the RedMine ticket at
[http://redmine.ruby-lang.org/issues/show/199]. It contains a
mostly-automated set of commands for downloading, compiling the new
Ruby, and running it against the various test suites. It also contains
full logs of my test output which demonstrate how the new code is
failing dozens of tests that the old stable releases passed. Please join
me in trying to figure out what's wrong and filing bug reports so that
the current Ruby branch can be improved.

-igal

Tanaka Akira

unread,
Jun 29, 2008, 12:01:20 AM6/29/08
to ruby...@ruby-lang.org
In article <48662E99...@pragmaticraft.com>,
Igal Koshevoy <ig...@pragmaticraft.com> writes:

> [http://redmine.ruby-lang.org/issues/show/199] and uploaded the
> following files:
> 1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
> the test suites

> 2. logs.tar.gz -- The test suite logs for the various programs

I read the logs of rubyspec.

I think there are bugs in Ruby and RubySpec.

Ruby bugs:
Module#remove_method
String#%
Iconv

RubySpec bugs:
BigDecimal
Date
ERB
REXML
Singleton#_dump
--
Tanaka Akira

Federico Builes

unread,
Jun 29, 2008, 12:13:09 AM6/29/08
to ruby...@ruby-lang.org

On Jun 28, 2008, at 11:01 PM, Tanaka Akira wrote:
> I read the logs of rubyspec.
>
> RubySpec bugs:
> BigDecimal
> Date
> ERB
> REXML
> Singleton#_dump

I'm not sure how's the situation with most of these libraries but I
was responsible for the REXML specs so let me chime in. P111 had a
_really_ buggy REXML revision with several typos/small bugs that were
(mostly) fixed in P114 so that might be a better target for
compatibility (for that library at least).

Anyway, if you consider there's a wrong spec somewhere in there please
let me know.
As for the other libraries, I'm sure we'll be checking them tomorrow
since what we consider a Ruby bugs usually goe together with a filled
bug report.

--
Federico

Tanaka Akira

unread,
Jun 29, 2008, 12:32:01 AM6/29/08
to ruby...@ruby-lang.org
In article <82FB5EC2-0775-4EAB...@gmail.com>,
Federico Builes <federic...@gmail.com> writes:

> I'm not sure how's the situation with most of these libraries but I
> was responsible for the REXML specs so let me chime in. P111 had a
> _really_ buggy REXML revision with several typos/small bugs that were
> (mostly) fixed in P114 so that might be a better target for
> compatibility (for that library at least).

Yes. REXML has typo.

This is an example of failure caused by typo.

| REXML::Document#add overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7580630>

> Anyway, if you consider there's a wrong spec somewhere in there please
> let me know.

The test has ruby_bug guard.

rubyspec/1.8/library/rexml/document/add_spec.rb:
| ruby_bug "#19058", "1.8.6.114" do

The test is run for 1.8.6p238 but not for ruby 1.8.6p114.
This causes rubyspec/1.8/17630.log has the above failure
which is not in rubyspec/1.8/p111.log in the reported log.

But this doesn't mean REXML in 1.8.6p238 has new bug or spec
change.
--
Tanaka Akira

Urabe Shyouhei

unread,
Jun 29, 2008, 1:41:27 AM6/29/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> For the sake of protecting Ruby's good image, I believe it's necessary
> to ship an *official* version that's compatible and addresses these
> vulnerabilities as soon as possible. After that's shipped, resolving
> the matter with the API changes in the current code will likely be a
> priority. If there's anything that we in the Ruby community can help
> you with, please ask. :)

Yes. Please write a patch :)

I know your concerns. I know you all need a stable Ruby, rather than a
beautifully working Ruby. Actually that's why I'm still maintaining
1.8.6. And sorry again for its unexpectedly unstable.

But honestly I'm doubtful for urgency of current situation. If things
are that dangerous someone might be writing patches, like some people
did for p230. I think p230 was dangerous enough. But now that fixes
are made, it seems it's less urgent. I think we should wait for fixes
made into 1.8.6, rather than reverting to p114 + a security fix. If you
can't wait please fix it by yourself; we are very grateful to merge that
into our repository. In other words, I think it's not that urgent
because no one seems to trying to fix those APIs.

Anyway, p238 source code can be downloaded via
http://svn.ruby-lang.org/repos/ruby/tags/v1_8_6_238

Igal Koshevoy

unread,
Jun 29, 2008, 5:58:56 AM6/29/08
to ruby...@ruby-lang.org
Federico Builes wrote:
> I'm not sure how's the situation with most of these libraries but I
> was responsible for the REXML specs so let me chime in. P111 had a
> _really_ buggy REXML revision with several typos/small bugs that were
> (mostly) fixed in P114 so that might be a better target for
> compatibility (for that library at least).
I'm glad you mentioned this. When I was talking about using a stable
p111, I mean the copy shipped with Ubuntu that's got 11 patches applied
to it, including the REXML fixes. It would be a worthwhile effort to
figure out what patches the various distros are using, making sure
they're providing a complete solution, and also ensuring that we're
incorporating these into the other solutions we've been throwing around.

Here's what some vendors are doing:

FreeBSD ports patches the vulnerability against p111:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/

Ubuntu 7.10 patches the vulnerability against p36:

https://launchpad.net/ubuntu/gutsy/+source/ruby1.8/1.8.6.36-1ubuntu3.2/+files/ruby1.8_1.8.6.36-1ubuntu3.2.diff.gz

Ubuntu 8.04 patches the vulnerability against p111:

https://launchpad.net/ubuntu/hardy/+source/ruby1.8/1.8.6.111-2ubuntu1.1/+files/ruby1.8_1.8.6.111-2ubuntu1.1.diff.gz

Fedora 9 patches the vulnerability against p230:

http://download.fedora.redhat.com/pub/fedora/linux/updates/9/SRPMS/ruby-1.8.6.230-2.fc9.src.rpm

RedHat Enterprise Linux 5.1, their latest, uses 1.8.5 and is vulnerable:

http://install.linux.duke.edu/pub/linux/updates/centos-5.1/SRPMS/ruby-1.8.5-5.el5_1.1.src.rpm

-igal

M. Edward (Ed) Borasky

unread,
Jun 29, 2008, 7:20:22 AM6/29/08
to ruby...@ruby-lang.org
Gentoo is using 1.8.6-p114 with two patches:

>>>> Emerging (1 of 1) dev-lang/ruby-1.8.6_p114 to /
> * ruby-1.8.6-p114.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ]
> * checking ebuild checksums ;-) ... [ ok ]
> * checking auxfile checksums ;-) ... [ ok ]
> * checking miscfile checksums ;-) ... [ ok ]
> * checking ruby-1.8.6-p114.tar.bz2 ;-) ... [ ok ]
>>>> Unpacking source...
>>>> Unpacking ruby-1.8.6-p114.tar.bz2 to /var/tmp/portage/dev-lang/ruby-1.8.6_p114/work
> * Applying ruby-1.8.6-memory-leak.diff ... [ ok ]
> * Applying ruby-1.8.6_p111-r13657.patch ... [ ok ]

Incidentally, Ruby 1.8.7 is in the Portage tree, but it's masked.

Igal Koshevoy

unread,
Jun 29, 2008, 7:31:21 AM6/29/08
to ruby...@ruby-lang.org
M. Edward (Ed) Borasky wrote:
> Igal Koshevoy wrote:
>> Federico Builes wrote:
>>> I'm not sure how's the situation with most of these libraries but I
>>> was responsible for the REXML specs so let me chime in. P111 had a
>>> _really_ buggy REXML revision with several typos/small bugs that
>>> were (mostly) fixed in P114 so that might be a better target for
>>> compatibility (for that library at least).
>> I'm glad you mentioned this. When I was talking about using a stable
>> p111, I mean the copy shipped with Ubuntu that's got 11 patches
>> applied to it, including the REXML fixes. It would be a worthwhile
>> effort to figure out what patches the various distros are using,
>> making sure they're providing a complete solution, and also ensuring
>> that we're incorporating these into the other solutions we've been
>> throwing around.
>>
>> Here's what some vendors are doing:
>>
>> FreeBSD ports patches the vulnerability against p111:
>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/ruby18/files/
>>
>> Ubuntu 7.10 patches the vulnerability against p36:
>>
>> https://launchpad.net/ubuntu/gutsy/+source/ruby1.8/1.8.6.36-1ubuntu3.2/+files/ruby1.8_1.8.6.36-1ubuntu3.2.diff.gz
>>
>>
>> Ubuntu 8.04 patches the vulnerability against p111:
>>
>> https://launchpad.net/ubuntu/hardy/+source/ruby1.8/1.8.6.111-2ubuntu1.1/+files/ruby1.8_1.8.6.111-2ubuntu1.1.diff.gz
>>
>> because.
Thanks for the info, Ed.

Providing support and patches for 1.8.5 may be necessary. The latest
releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or "stable"),
SUSE, and possibly others are still shipping 1.8.5 and will be
frustrated by the abrupt termination of updates.

-igal

Igal Koshevoy

unread,
Jun 29, 2008, 7:59:51 AM6/29/08
to ruby...@ruby-lang.org
Thank you both for the reviews and for clarifying the situation with the
guard conditions. I've read up on the topic at
http://rubyspec.org/wiki/rubyspec/Guards

As I understand this, the #ruby_bug method silently acts as if the
example passed when run on an implementation with a known bug. Shouldn't
this provide some warning, kind of like RSpec treats "pending"?

The SVN r17630 Ruby that I tested still has this bug that Federico
Builes reported and provided a patch for three months ago.

The spec says that the bug is only present up to p114, but if the patch
was never officially applied, shouldn't the guard condition be updated
or relaxed?

-igal

Urabe Shyouhei

unread,
Jun 29, 2008, 8:05:32 AM6/29/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> Providing support and patches for 1.8.5 may be necessary. The latest
> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or
> "stable"), SUSE, and possibly others are still shipping 1.8.5 and will
> be frustrated by the abrupt termination of updates.
>
> -igal

1.8.5 life-span has been scheduled and informed at least since 2006,
plus, to be frank, we have no human resources remaining to prolong this
version.

I will never stop YOU to maintenance 1.8.5; forking Ruby is your
right. And some OS vendors may actually do so. But do not expect
further support by us.

Igal Koshevoy

unread,
Jun 29, 2008, 8:45:30 AM6/29/08
to ruby...@ruby-lang.org
Urabe Shyouhei wrote:
> 1.8.5 life-span has been scheduled and informed at least since 2006,
> plus, to be frank, we have no human resources remaining to prolong this
> version.
>
Just to confirm, you're terminating support for 1.8.5 and all earlier
releases?

> I will never stop YOU to maintenance 1.8.5; forking Ruby is your
> right. And some OS vendors may actually do so. But do not expect
> further support by us.

What if resources for keeping 1.8.5 on life support could be found and
provided by members outside the current Ruby core developer team and
these people met whatever criteria you set for them? Would your team be
willing to consider providing them with a way to continue to make
official Ruby 1.8.5 releases and distribute them from ruby-lang.org?

-igal

Igal Koshevoy

unread,
Jun 29, 2008, 9:27:37 AM6/29/08
to ruby...@ruby-lang.org
Tanaka Akira wrote:
> In article <48662E99...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>> [http://redmine.ruby-lang.org/issues/show/199] and uploaded the
>> following files:
>> 1. wrapper.sh -- Sample commands I'm running to build Ruby and execute
>> the test suites
>> 2. logs.tar.gz -- The test suite logs for the various programs
>>
> I read the logs of rubyspec.
>
>
> I think there are bugs in Ruby and RubySpec.
>
Thank you for the help!

> Ruby bugs:
> Module#remove_method
> String#%
> Iconv
>

I agree, these seem to be bugs in the current implementation of Ruby and
these definitely worked earlier.

> RubySpec bugs:
> BigDecimal
> Date
>
I agree. But how should these be fixed? The spec examples say these bugs
only exist in Ruby versions up to and including p114, but these bugs
still exist. Should the patchlevel value in these examples be updated to
p238 or should it be set to a more general value, like :ruby18, to
indicate that no known version of MRI 1.8 can pass this test?

> RubySpec bugs:
> [...]
> ERB
> REXML
> Singleton#_dump
>
I think these are bugs in Ruby, not in RubySpec. The code in these
worked correctly without any guard conditions on my older interpreter,
therefore if the new version is failing these, something has changed.
Can you or someone else please review these specs to confirm this?

Just to be clear, REXML has some errors due to the guard conditions
explained in the "RubySpec bugs" section above. However, some of the
REXML errors were in examples without guard conditions, therefore I
think they're Ruby errors.

The above list is all the errors that were flagged for attention in the
RubySpec logs. Bugs in String#%, Iconv, ERB and REXML bugs are fairly
important given that these are widely used.

Is there a way to generate code coverage reports for both the C and Ruby
code being run? This would really provide a better idea of how complete
RubySpec really is.

I'm delighted that we have RubySpecs to help us. Thank you for the hard
work: Brian Ford, Federico Builes, Arthur Schreiber, and all the other
contributors. You're providing a valuable service to the Ruby community. :)

-igal

Tanaka Akira

unread,
Jun 29, 2008, 9:53:42 AM6/29/08
to ruby...@ruby-lang.org
In article <48678E3D...@pragmaticraft.com>,
Igal Koshevoy <ig...@pragmaticraft.com> writes:

> I think these are bugs in Ruby, not in RubySpec. The code in these
> worked correctly without any guard conditions on my older interpreter,
> therefore if the new version is failing these, something has changed.
> Can you or someone else please review these specs to confirm this?

ERB tests compare Ruby code generated internaly in ERB.
It is internal of ERB. RubySpec shouldn't specify library
internals.

Singleton#_dump should be public. It is discussed recently
in ruby-core. This is a bug fix. RubySpec shouldn't
specify a bug.

> Just to be clear, REXML has some errors due to the guard conditions
> explained in the "RubySpec bugs" section above. However, some of the
> REXML errors were in examples without guard conditions, therefore I
> think they're Ruby errors.

Do you want to fix REXML problems in 1.8.6 line?
--
Tanaka Akira

Igal Koshevoy

unread,
Jun 29, 2008, 10:47:31 AM6/29/08
to ruby...@ruby-lang.org
Urabe Shyouhei wrote:
> Igal Koshevoy wrote:
>
>> For the sake of protecting Ruby's good image, I believe it's necessary
>> to ship an *official* version that's compatible and addresses these
>> vulnerabilities as soon as possible. After that's shipped, resolving
>> the matter with the API changes in the current code will likely be a
>> priority. If there's anything that we in the Ruby community can help
>> you with, please ask. :)
>>
>
> Yes. Please write a patch :)
>
I'll try to help with the Ruby patches, but I don't know C well enough
to offer assistance.

> I know you all need a stable Ruby, rather than abeautifully working Ruby.

I love Ruby because it's beautiful. But the people that pay me don't
care about beauty, only stability. :/

> But honestly I'm doubtful for urgency of current situation. If things
> are that dangerous someone might be writing patches, like some people
> did for p230. I think p230 was dangerous enough. But now that fixes
> are made, it seems it's less urgent.

Please release an official fix and soon. The urgency is that it's now
been 9 days and there's no official solution to the vulnerabilities
reported and the segmentation faults in p230.

Ruby user's options for resolving this currently are very problematic.
They either must scour websites and mailing lists for patches, and
personally decide which of these complex unofficial patches to use,
which is far beyond most people's ability. Meanwhile, many OS vendors
have lost patience and are now beginning to ship patched versions, but
they're also making guesses about how to patch this.

The Ruby community and distros are waiting for an *official* release
that provides a solution to these problems.

Although p238 breaks some things, it's better than the
officially-released p230 version. This p238 may be worth releasing
because it addresses the immediate problems with that failed release and
passes the Rails and RSpec test suites just as well as the Ubuntu
patched p111 version that I was comparing it to. But please note that I
can't evaluate the C code, so I'm entirely depending on your judgment
about whether it's ready.

Depending on how long it takes to address the compatibility issues
uncovered by RubySpec, it may make sense to ship p238 now and ship
another release with the compatibility fixes as soon as they're ready.

-igal

Igal Koshevoy

unread,
Jun 29, 2008, 11:11:11 AM6/29/08
to ruby...@ruby-lang.org
Tanaka Akira wrote:
> In article <48678E3D...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>
>
>> I think these are bugs in Ruby, not in RubySpec. The code in these
>> worked correctly without any guard conditions on my older interpreter,
>> therefore if the new version is failing these, something has changed.
>> Can you or someone else please review these specs to confirm this?
>>
>
> ERB tests compare Ruby code generated internaly in ERB.
> It is internal of ERB. RubySpec shouldn't specify library
> internals.
>
Ah! Correct. I've reviewed that code more carefully and see what you
mean. The ERB spec is comparing the Ruby code generated, which it really
should be comparing just the output.

> Singleton#_dump should be public. It is discussed recently
> in ruby-core. This is a bug fix. RubySpec shouldn't
> specify a bug.
>

I see, thank you for the explanation.

>> Just to be clear, REXML has some errors due to the guard conditions
>> explained in the "RubySpec bugs" section above. However, some of the
>> REXML errors were in examples without guard conditions, therefore I
>> think they're Ruby errors.
>>
> Do you want to fix REXML problems in 1.8.6 line?
>

I'd personally like to see the patch that Federico Builes reviewed,
improved and applied if it seems reasonable. At the very least, Ruby
shouldn't be shipping a library that fails due to a syntax error in it.

However, there are some unguarded REXML examples that are failing, which
may indicate a new Ruby bug/incompatibility. I also think there's
another Ruby problem exposed by "library/bigdecimal/divmod_spec.rb". So
if you or someone else can review these, I'd appreciate it.

So the list of things we think may be broken based on reviewing
RubySpec's logs seem to be:
Module#remove_method
String#%
Iconv
ERB (?)
BigDecimal (?)

Thank you again for the assistance.

-igal

Tanaka Akira

unread,
Jun 29, 2008, 11:29:05 AM6/29/08
to ruby...@ruby-lang.org
In article <4867A6AC...@pragmaticraft.com>,
Igal Koshevoy <ig...@pragmaticraft.com> writes:

> However, there are some unguarded REXML examples that are failing, which
> may indicate a new Ruby bug/incompatibility.

In your log, which is not guarded?

| 36)


| REXML::Document#add overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7580630>

| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:80:in `add'
| ./library/rexml/document/add_spec.rb:40
|
| 37)
| REXML::Document#<< overwrites existing DocType ERROR
| NoMethodError: undefined method `kind_of' for #<REXML::DocType:0xb7579024>
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:80:in `add'
| ./library/rexml/document/add_spec.rb:40
|
| 38)
| REXML::Document#write returns document with transitive support ERROR
| ArgumentError: wrong number of arguments (2 for 1)
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `initialize'
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `new'
| /home/igal/mtmp/rubyfix/ruby_1_8_6/../ruby-svn17630/lib/ruby/1.8/rexml/document.rb:188:in `write'
| ./library/rexml/document/write_spec.rb:33
|
| 39)
| REXML::Element#delete_element deletes Element and returns it FAILED
| Expected nil
| to equal <some_node/>
|
| /home/igal/mtmp/rubyfix/ruby-svn17630/lib/ruby/gems/1.8/gems/mspec-1.0.0/lib/mspec/expectations/expectations.rb:10:in `fail_with'
| /home/igal/mtmp/rubyfix/ruby-svn17630/lib/ruby/gems/1.8/gems/mspec-1.0.0/lib/mspec/matchers/base.rb:8:in `=='
| ./library/rexml/element/delete_element_spec.rb:35
--
Tanaka Akira

Urabe Shyouhei

unread,
Jun 29, 2008, 11:39:54 AM6/29/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> Urabe Shyouhei wrote:
>> 1.8.5 life-span has been scheduled and informed at least since 2006,
>> plus, to be frank, we have no human resources remaining to prolong this
>> version.
>>
> Just to confirm, you're terminating support for 1.8.5 and all earlier
> releases?

Yes. All releases prior to 1.8.5, including all 1.4 series and all 1.6
series, are not supported any longer.
Also for a side note, support for 1.8.6 will be terminated once we
release 1.8.8. Support for 1.8.7 will also be terminated once we
release 1.8.9.

>> I will never stop YOU to maintenance 1.8.5; forking Ruby is your
>> right. And some OS vendors may actually do so. But do not expect
>> further support by us.
> What if resources for keeping 1.8.5 on life support could be found and
> provided by members outside the current Ruby core developer team and
> these people met whatever criteria you set for them?

That's great. Far better than I can imagine.

> Would your team be willing to consider providing them with a way to
> continue to make official Ruby 1.8.5 releases and distribute them from
> ruby-lang.org?

This is my personal opinion but it's OK for a new mentor to get a full
control of everything to officially release 1.8.5. Final decision
should be made by matz so I cannot tell any particular thing but, I
wish he says yes.

Igal Koshevoy

unread,
Jun 29, 2008, 12:51:03 PM6/29/08
to ruby...@ruby-lang.org
Tanaka Akira wrote:
> In article <4867A6AC...@pragmaticraft.com>,
> Igal Koshevoy <ig...@pragmaticraft.com> writes:
>
>> However, there are some unguarded REXML examples that are failing, which
>> may indicate a new Ruby bug/incompatibility.
>>
>
> In your log, which is not guarded?
>
Sorry, I was wrong. I've reviewed all the REXML errors and they seem to
be accounted for by stale version numbers in the spec.

The current guard lines read like this:
ruby_bug "#17910", "1.8.6.114" do

What should these sorts of lines be changed to if no official version of
MRI supports the code in these examples? "1.8.6"? "1.8"?

-igal

M. Edward (Ed) Borasky

unread,
Jun 29, 2008, 1:03:48 PM6/29/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> Providing support and patches for 1.8.5 may be necessary. The latest
> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or "stable"),
> SUSE, and possibly others are still shipping 1.8.5 and will be
> frustrated by the abrupt termination of updates.

RHEL *5* is still using 1.8.5? In that case, dropping support for 1.8.5
is a *huge* problem. RHEL *4* using 1.8.5 I think the world could deal
with. After all, Red Hat is always going to market their own upgrades
aggressively, and anybody who's still on RHEL 3/2.4.21-EL deserves what
they get. :)

I'm not all that concerned about Etch. It's fairly rare in the server
world, it's not really "marketed", and Debian's Ruby packaging structure
isn't particularly well-liked by Rubyists. You're probably more likely
to see a Fedora server than one running Etch. If I were running a Debian
server I'd simply put Ruby up from source. What about the paid-for
versions of Novell SuSE?


Federico Builes

unread,
Jun 29, 2008, 1:26:20 PM6/29/08
to ruby...@ruby-lang.org

On Jun 29, 2008, at 11:51 AM, Igal Koshevoy wrote:
> The current guard lines read like this:
> ruby_bug "#17910", "1.8.6.114" do
>
> What should these sorts of lines be changed to if no official
> version of MRI supports the code in these examples? "1.8.6"? "1.8"?

The correct guard in this case should be 1.8 as you propose. I'll be
taking a look at the specs this afternoon to ensure it's correctly
guarded, but remember REXML is kept in a separate repository so
there's a chance that these issues have been already corrected there
(I know some of the bug reports were ported).

--
Federico

M. Edward (Ed) Borasky

unread,
Jun 29, 2008, 4:07:49 PM6/29/08
to ruby...@ruby-lang.org
M. Edward (Ed) Borasky wrote:
> Igal Koshevoy wrote:
>> Providing support and patches for 1.8.5 may be necessary. The latest
>> releases of RedHat Enterprise Linux, Debian Etch (AKA "4" or
>> "stable"), SUSE, and possibly others are still shipping 1.8.5 and will
>> be frustrated by the abrupt termination of updates.
>
> RHEL *5* is still using 1.8.5? In that case, dropping support for 1.8.5
> is a *huge* problem. RHEL *4* using 1.8.5 I think the world could deal
> with. After all, Red Hat is always going to market their own upgrades
> aggressively, and anybody who's still on RHEL 3/2.4.21-EL deserves what
> they get. :)

Well ... it looks like RHEL 5 *is* using 1.8.5:

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ruby-1.8.5-5.el5_1.1.src.rpm

dated 12 November 2007.

What are the odds that Red Hat corporate will put manpower onto
supporting Ruby 1.8.5? This is a security issue, and they pretty much
have to fix it. I don't know anyone there, nor do I own any licenses. I
do from time to time experiment with the CentOS and Scientific Linux
re-spins of RHEL 5, but they have to wait for Red Hat to release the
source RPM.

Urabe Shyouhei

unread,
Jun 29, 2008, 11:44:43 PM6/29/08
to ruby...@ruby-lang.org
M. Edward (Ed) Borasky wrote:
> RHEL *5* is still using 1.8.5? In that case, dropping support for
> 1.8.5 is a *huge* problem. RHEL

Why on earth?

We are not cat's-paw of RedHat, nor Sun, nor Microsoft; we are
individual from any OS vendors. It is quite natural for them to have
different maintenance plan than ours. Equally natural for us to have
different plans than theirs.

Joel VanderWerf

unread,
Jun 30, 2008, 12:57:38 AM6/30/08
to ruby...@ruby-lang.org

Bravo.

The Ruby core developers are hardly going to get any work done if they
are supporting more than 2 or 3 releases at a time. Let the distributors
keep up with the developers, rather than drag them down. As long as
there is a current stable release, everyone who wants a stable ruby
should move their code to it (how hard can it be to move from 1.8.5. to
1.8.6, especially since 1.8.5 was a bit problematic itself, IIRC).

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Urabe Shyouhei

unread,
Jul 2, 2008, 6:41:58 AM7/2/08
to ruby...@ruby-lang.org
Hello, I think current 1.8.6/1.8.7 is stable than p230/p22, so I decided
to release them again. Expected date for that is Jul. 4 (in Japanese
Timezone).

Can you check to see if they works on your machine? I don't want to
release again and again (that make users confuse.) I want to make next
release acceptable for you.

M. Edward (Ed) Borasky

unread,
Jul 2, 2008, 9:36:09 AM7/2/08
to ruby...@ruby-lang.org
How do we get these exact versions? Are there tarballs, or do I need
some Subversion code to check out the exact source?

Vladimir Sizikov

unread,
Jul 2, 2008, 10:51:12 AM7/2/08
to ruby...@ruby-lang.org
Hi Urabe,

* 1.8.6 HEAD has 7 rubyspec falures for StringIO
* 1.8.7 HEAD has *57* rubyspec failures for StringIO

Take a look here (for 1.8.7 faliures)
http://pastie.org/226299

Would it be possible to fix at least 1.8.7 branch?

Please note that 1.8 HEAD passes all 100% StringIO rubyspecs.

Thanks,
--Vladimir

Charles Oliver Nutter

unread,
Jul 2, 2008, 10:55:51 AM7/2/08
to ruby...@ruby-lang.org
Vladimir Sizikov wrote:
> Hi Urabe,
>
> * 1.8.6 HEAD has 7 rubyspec falures for StringIO
> * 1.8.7 HEAD has *57* rubyspec failures for StringIO
>
> Take a look here (for 1.8.7 faliures)
> http://pastie.org/226299
>
> Would it be possible to fix at least 1.8.7 branch?
>
> Please note that 1.8 HEAD passes all 100% StringIO rubyspecs.

There should not be a release until the failures in rubyspec are addressed.

- Charlie

Igal Koshevoy

unread,
Jul 2, 2008, 2:36:00 PM7/2/08
to ruby...@ruby-lang.org
Urabe Shyouhei wrote:
> Hello, I think current 1.8.6/1.8.7 is stable than p230/p22
I think so too. However, there are still some problems that may be
serious, such as the breakage of Iconv.

> Can you check to see if they works on your machine? I don't want to
> release again and again (that make users confuse.) I want to make next
> release acceptable for you.

I've re-run the test suites, along with some additional ones, against
Ruby 1.8.6 SVN 17631 and the results seem promising.

The RubySpec team's been working hard to expand their specs and
eliminate the false positives I reported last time. Many thanks to
Federico Builes, Vladimir Sizikov, Arthur Schreiber, Tanaka Akira, Brian
Ford, and others for the timely effort.

Here are the latest results from the test suites:

RubySpec [Wed Jul 2 11:27:11 2008 -0500]
* Module#remove_method fails
* String#% failures
* Iconv has many, many failures

Rails 1.2.6
* Fine!

Rails 2.0.2
* Fine!

Rails 2.1.0
* Fine!

Rails tip
* Hundreds of tests seem to be skipped, haven't figured out why.

RSpec 1.1.4
* Fine. Although it fails the 'identical HTML' spec, that spec is flaky
and shouldn't count.

Complete, updated logs: http://redmine.ruby-lang.org/attachments/download/15

Please double-check my findings.

-igal

Igal Koshevoy

unread,
Jul 2, 2008, 2:45:28 PM7/2/08
to ruby...@ruby-lang.org
We've got a potential problem that's not being caught by the specs:
memory leaks.

Two separate users have reported leaks when running p230 with the
Smartleaf patch, while having no such problems when running p111/p114
backported versions. Because the Smartleaf patch simply reverts some
refactoring to resolve segfaults, it's unlikely that its causing the
leaks, and the probable source is changes introduced into Ruby itself
between p114 and p230. Here's a link to that other thread
http://www.ruby-forum.com/topic/157034#697304

I've asked both of those reporting the problem to give us further
information, but it may be difficult for them to do, especially since
both are trying to stabilize their apps and may not have time for debugging.

Can someone please try to come up with a way to reproduce this memory
leak with p230 and confirm whether it's been resolved with p238?

Thanks!

-igal

Vladimir Sizikov

unread,
Jul 2, 2008, 3:31:16 PM7/2/08
to ruby...@ruby-lang.org
Hi,

I'd strongly suggest to postpone 1.8.7 release untill te majority of
the rubyspec failures is fixed. I already reported 57 StringIO
failures. There are also *127* String rubyspec failures (thanks to
Federico Builes for reminding me about those).

Please note that 1.8 HEAD passes all tests (so the fixes are already there).

Also, I see some securerandom spec failues with 1.8.7 head, while 1.8
HEAD is clean.

P.S. There could be more reports from RubySpec folks who are currently
running the tests.

Thanks,
--Vladimir

On Wed, Jul 2, 2008 at 12:41 PM, Urabe Shyouhei <shyo...@ruby-lang.org> wrote:

Luis Lavena

unread,
Jul 2, 2008, 6:05:43 PM7/2/08
to ruby...@ruby-lang.org
On Wed, Jul 2, 2008 at 12:41 PM, Urabe Shyouhei <shyo...@ruby-lang.org> wrote:

I'm not happy to inform that the make test-all procedure still stall
in test_07_public_private_protected_missing(TestDRbCore) for
i386-mingw32 platform.

Tested with SVN:

http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6
revision: 17815

Our testing procedure uses the same version of ruby just build to host
the test and also serve as baseruby (adding it to the path before the
one used to actually build the sandbox).

This procedure has worked for us in the past, even way before I made
public the sandbox project repository.

Moreover, I'll like to mention that I can replicate the same behavior
using many version of base ruby and many Windows XP and Vista 32bits
installation, since the sanbox of RubyInstaller is designed to make it
easy recreate the whole environment:

http://github.com/luislavena/rubyinstaller

On the other hand, using 1.8.6-p114, even with the patches [1]
applied, still passes those tests.

I'll likely help tracking this issue down, but the several
branches/tags per-commit make it hard and very difficult to obtain a
clear commit/log history to determine the correct place of those
issues and revert or fix the ones affecting us.

[1] http://www.rubyinstaller.org/patches/

Regards,
--
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

Urabe Shyouhei

unread,
Jul 2, 2008, 11:30:46 PM7/2/08
to ruby...@ruby-lang.org
Charles Oliver Nutter wrote:
> There should not be a release until the failures in rubyspec are
> addressed.

OK, so all of you can wait until rubyspec passes? I think I cannot
review every failures in a 24 hours so releases should be delayed. Is it
really OK?

I'm neutral whether we should make an immediate release, or we need more
brush-up to release.

Federico Builes

unread,
Jul 2, 2008, 11:54:51 PM7/2/08
to ruby...@ruby-lang.org

On Jul 2, 2008, at 10:30 PM, Urabe Shyouhei wrote:

> Charles Oliver Nutter wrote:
>> There should not be a release until the failures in rubyspec are
>> addressed.
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed.
> Is it
> really OK?

We'd appreciate it if you could hold on a bit. Most of the current
failures are related to Iconv, StringIO (reported by Vladimir Sizikov
in 17504) and the EditLine wrapper for OS X users (17479).

Memory leaks reported in http://redmine.ruby-lang.org/issues/show/216
should be checked too.

Thanks.

--
Federico

Federico Builes

unread,
Jul 3, 2008, 1:01:39 AM7/3/08
to ruby...@ruby-lang.org

On Jul 2, 2008, at 2:31 PM, Vladimir Sizikov wrote:

> P.S. There could be more reports from RubySpec folks who are currently
> running the tests.

I'll chime in here and post some more results:

* Iconv

The version of Iconv bundled in 1.8.6 HEAD has 16 spec failures:
- http://pastie.caboo.se/paste/226883
The version of Iconv bundled in 1.8.7 HEAD has 3 spec failures:
- http://pastie.caboo.se/paste/226885

You can see the full specs in:
- http://github.com/rubyspec/rubyspec/tree/master/1.8/library/iconv

If you consider any of these behaviors to be wrong please let us know.

* BasicSocket#close_read

The current implementation in 1.8 and 1.9 allows the user to call
close_read (or close_write) twice on a socket without raising errors.

s = Socket.new(AF_INET, SOCK_STREAM, 0)
s.bind(Socket.pack_sockaddr_in(9999, "localhost")
s.close_read
s.close_read # No errors raised

Contrast this with IO#close_read(and #close_write) which will raise an
IOError if you try to close an already closed end.

What behavior should we spec in this case?

--
Federico

Tanaka Akira

unread,
Jul 3, 2008, 1:47:54 AM7/3/08
to ruby...@ruby-lang.org
In article <99302F3B-C06B-4B53...@gmail.com>,
Federico Builes <federic...@gmail.com> writes:

> * Iconv
>
> The version of Iconv bundled in 1.8.6 HEAD has 16 spec failures:
> - http://pastie.caboo.se/paste/226883
> The version of Iconv bundled in 1.8.7 HEAD has 3 spec failures:
> - http://pastie.caboo.se/paste/226885

What the revision or patchlevel of the "HEAD"?
What the output of "ruby -v"?

It seems iconv.c in 1.8.6 and 1.8.7 differs only comments now.
So they should behave similar.

% svn diff http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_6/ext/iconv/iconv.c http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8_7/ext/iconv/iconv.c
Index: iconv.c
===================================================================
--- iconv.c (.../ruby_1_8_6/ext/iconv/iconv.c) (revision 17840)
+++ iconv.c (.../ruby_1_8_7/ext/iconv/iconv.c) (revision 17840)
@@ -43,8 +43,12 @@
...

> You can see the full specs in:
> - http://github.com/rubyspec/rubyspec/tree/master/1.8/library/iconv
>
> If you consider any of these behaviors to be wrong please let us know.

As far as nobu's opinion, [ruby-core:17127], RubySpec
specifys bug behavior.

> * BasicSocket#close_read
>
> The current implementation in 1.8 and 1.9 allows the user to call
> close_read (or close_write) twice on a socket without raising errors.
>
> s = Socket.new(AF_INET, SOCK_STREAM, 0)
> s.bind(Socket.pack_sockaddr_in(9999, "localhost")
> s.close_read
> s.close_read # No errors raised
>
> Contrast this with IO#close_read(and #close_write) which will raise an
> IOError if you try to close an already closed end.
>
> What behavior should we spec in this case?

I feel it should cause an error.

Successive shutdown system calls doesn't fail, though.

% strace ruby -rsocket -e 's1, s2 = UNIXSocket.pair; 10.times { s1.close_read }'
...
socketpair(PF_FILE, SOCK_STREAM, 0, [3, 4]) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
shutdown(3, 0 /* receive */) = 0
...
--
Tanaka Akira

U.Nakamura

unread,
Jul 3, 2008, 2:17:51 AM7/3/08
to ruby...@ruby-lang.org
Hello,

In message "[ruby-core:17517] Re: We'll release 1.8.6/1.8.7 this Friday"


on Jul.03,2008 07:05:43, <luisl...@gmail.com> wrote:
> I'm not happy to inform that the make test-all procedure still stall
> in test_07_public_private_protected_missing(TestDRbCore) for
> i386-mingw32 platform.

I can't reproduce it with mswin32...

Can you test with reverting r17290 (socket changes)?


Regards,
--
U.Nakamura <u...@garbagecollect.jp>


Federico Builes

unread,
Jul 3, 2008, 2:29:59 AM7/3/08
to ruby...@ruby-lang.org

On Jul 3, 2008, at 12:47 AM, Tanaka Akira wrote:

> It seems iconv.c in 1.8.6 and 1.8.7 differs only comments now.
> So they should behave similar.

You're right, I was testing against 1.8.6p255 but p264 seems to fix
the issue and fail the same specs that 1.8.7 was failing. We'll look
into it.

> I feel it should cause an error.
> Successive shutdown system calls doesn't fail, though.

We'll spec this behavior then, thanks for your support.

--
Federico

Vladimir Sizikov

unread,
Jul 3, 2008, 2:39:09 AM7/3/08
to ruby...@ruby-lang.org
Hi Shyouhei,

On Thu, Jul 3, 2008 at 5:30 AM, Urabe Shyouhei <shyo...@ruby-lang.org> wrote:
> Charles Oliver Nutter wrote:
>> There should not be a release until the failures in rubyspec are
>> addressed.
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed.

It seems to me that the majority of String and StringIO failures is
caused by common cause and removing it will bring that huge number of
failing specs down.

> Is it really OK?

This is perfectly OK with me :)

> I'm neutral whether we should make an immediate release, or we need more
> brush-up to release.

There are multiple folks looking at and working on RubySpecs now,
including 3 Google Sommer of Code students, so it is a perfect
opportunity to make next Ruby release as good as possible and to
improve RubySpecs too.

Feel free to join #rubyspec IRC on freenode, most folks hang out
there, so we could shorten the failures evaluation time and help out
in any way we could.

Thanks,
--Vladimir

Tanaka Akira

unread,
Jul 3, 2008, 2:43:15 AM7/3/08
to ruby...@ruby-lang.org
In article <942C7C70-E389-4DDA...@gmail.com>,
Federico Builes <federic...@gmail.com> writes:

> We'll spec this behavior then, thanks for your support.

Note that my feeling is not the decision of ruby.

Ask matz for that.
--
Tanaka Akira

Luis Lavena

unread,
Jul 3, 2008, 3:16:34 AM7/3/08
to ruby...@ruby-lang.org
On Thu, Jul 3, 2008 at 8:17 AM, U.Nakamura <u...@garbagecollect.jp> wrote:
> Hello,
>
> In message "[ruby-core:17517] Re: We'll release 1.8.6/1.8.7 this Friday"
> on Jul.03,2008 07:05:43, <luisl...@gmail.com> wrote:
>> I'm not happy to inform that the make test-all procedure still stall
>> in test_07_public_private_protected_missing(TestDRbCore) for
>> i386-mingw32 platform.
>
> I can't reproduce it with mswin32...
>
> Can you test with reverting r17290 (socket changes)?
>
>

The bad thing is I don't have my VC6 environment to reproduce it
accurately (running on my laptop right now).

Reverting the specified revision fix the issue:


> Regards,
> --
> U.Nakamura <u...@garbagecollect.jp>
>
>
>

1588 tests, 15068 assertions, 3 failures, 0 errors
http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw

Those are the same errors that are failing under p114, which is nice.

One comment about r17290 is that it previously worked, since before
1.8.7 was released I've been able to use ruby_1_8 branch, which
included the same backport.

Now I'll run the specs to avoid missing something.

Thanks for your time.

schreibe...@googlemail.com

unread,
Jul 3, 2008, 3:53:43 AM7/3/08
to ruby...@ruby-lang.org
Hi Vladimir, hi Urabe,

Most of these 57 rubyspec failures are caused by the convert_type
change, that made convert_type check for private methods, too. This
change has already been reverted in 1.8.6 and 1.8 HEAD (even in
1.8.5), but not yet in 1.8.7.

Simply backporting http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=17396
into the 1.8.7 branch should fix these and many, many more failures
that we are currently seeing when running the latest 1.8.7 versions
against the rubyspecs.

Thanks, Arthur

On 2 Jul., 16:51, "Vladimir Sizikov" <vsizi...@gmail.com> wrote:
> Hi Urabe,
>
> * 1.8.6 HEAD has 7 rubyspec falures for StringIO
> * 1.8.7 HEAD has *57* rubyspec failures for StringIO
>

> Take a look here (for 1.8.7 faliures)http://pastie.org/226299

U.Nakamura

unread,
Jul 3, 2008, 4:01:17 AM7/3/08
to ruby...@ruby-lang.org
Hello,

In message "[ruby-core:17530] Re: We'll release 1.8.6/1.8.7 this Friday"


on Jul.03,2008 16:16:34, <luisl...@gmail.com> wrote:
> > Can you test with reverting r17290 (socket changes)?

Oh, sorry, I'd mistaken.
These are select changes, not socket changes.


> Reverting the specified revision fix the issue:
>

> 1588 tests, 15068 assertions, 3 failures, 0 errors
> http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw
>
> Those are the same errors that are failing under p114, which is nice.

Good news :)


> One comment about r17290 is that it previously worked, since before
> 1.8.7 was released I've been able to use ruby_1_8 branch, which
> included the same backport.

Hmm...

I consider four senarios.

1) drb changes cause this problem.

2) ext/socket changes cause this problem.

3) win32/win32.c changes cause this problem.

4) another changes cause this problem.

First, drb was not changed between p114 and p230. So, drb is
not guilty.
Second, ext/socket was changed, but it doesn't seems to affect.
Third, win32/win32.c contains the changes about select. These
are very suspicious.
Fourth, ... I have no idea :(

So, I suggested to revert r17290.


On ruby_1_8 branch, ext/socket changes are older than win32's
select changes.
So, probably ext/socket changes doesn't cause it, too.

BTW, r17290 is tagged as p207.
So, if p207 has same problem, ruby_1_8_6 needs something to
backport from ruby_1_8.
If p207 doesn't has the problem, something between p208 and
p230 causes it.
Luis, could you test p207, please?


Regards,
--
U.Nakamura <u...@garbagecollect.jp>


gde...@attglobal.net

unread,
Jul 3, 2008, 4:07:17 AM7/3/08
to ruby...@ruby-lang.org
Tim,

I am pleased to say that I finally got the payment
made earlier today. Sorry for the delay.

graeme

---- Original Message ----

U.Nakamura

unread,
Jul 3, 2008, 4:13:37 AM7/3/08
to ruby...@ruby-lang.org
Hello,

In message "[ruby-core:17533] Re: We'll release 1.8.6/1.8.7 this Friday"


on Jul.03,2008 17:01:17, <u...@garbagecollect.jp> wrote:
> > Reverting the specified revision fix the issue:
> >
> > 1588 tests, 15068 assertions, 3 failures, 0 errors
> > http://pastie.org/private/xk8thrwcbzeb2h1s7lm3tw
> >
> > Those are the same errors that are failing under p114, which is nice.
>
> Good news :)
>
>
> > One comment about r17290 is that it previously worked, since before
> > 1.8.7 was released I've been able to use ruby_1_8 branch, which
> > included the same backport.

Now I've decided to revert r17290 from ruby_1_8_6 in consultation
with Urabe-san.
r17290 solves the "gets blocks another threads" problem, but I
consider that the problem is the limitation in specification of
ruby_1_8_6, not a bug.


Regards,
--
U.Nakamura <u...@garbagecollect.jp>


Luis Lavena

unread,
Jul 3, 2008, 4:25:48 AM7/3/08
to ruby...@ruby-lang.org

Done, the test stall.

We can attribute this to the gets() and thread as you suggested in your email.

In any case, the mix gets() and Thread on Windows is something that
needs more attention taking in consideration all those changes.
(Part Heesob from win32utils worked on a new version for it, but still
imperfect).

Thank you again Mr. Nakamura for your time and your work looking into
this issue.

Regards,

U.Nakamura

unread,
Jul 3, 2008, 4:43:58 AM7/3/08
to ruby...@ruby-lang.org
Hello,

In message "[ruby-core:17536] Re: We'll release 1.8.6/1.8.7 this Friday"


on Jul.03,2008 17:25:48, <luisl...@gmail.com> wrote:
> > BTW, r17290 is tagged as p207.
> > So, if p207 has same problem, ruby_1_8_6 needs something to
> > backport from ruby_1_8.
> > If p207 doesn't has the problem, something between p208 and
> > p230 causes it.
> > Luis, could you test p207, please?
>
> Done, the test stall.

Thank you!

OK, r17290 needs something more, maybe it's ruby core changes.
If we find it and it is merged into ruby_1_8_6, r17290 will
be mereged again.
But, next release of ruby_1_8_6 will be shipped without r17290
because there is no time to find and test it.


> We can attribute this to the gets() and thread as you suggested in your email.
>
> In any case, the mix gets() and Thread on Windows is something that
> needs more attention taking in consideration all those changes.

I agree.


> Thank you again Mr. Nakamura for your time and your work looking into
> this issue.

It is I who should express gratitude.
Thank you, Luis.


Regards,
--
U.Nakamura <u...@garbagecollect.jp>


Michal Suchanek

unread,
Jul 3, 2008, 6:50:30 AM7/3/08
to ruby...@ruby-lang.org

While it is nice to have a release on the planned date I find the
quality of the release much more important.

The security release of 1.8.6p230 which contained a lot of untested
changes caused a lot of headache.

Thus delaying the release when problems are found is much better then
releasing known broken code. People who want to start testing at the
scheduled date can always check out from svn.

It may or may not be feasible to set up automated testing of the code
as each commit is done but testing at least the release is important
in my view.

Thanks

Michal

Urabe Shyouhei

unread,
Jul 3, 2008, 7:12:31 AM7/3/08
to ruby...@ruby-lang.org
Thank you, I merged this revision into 1.8.7.

Tanaka Akira

unread,
Jul 3, 2008, 7:56:33 AM7/3/08
to ruby...@ruby-lang.org
In article <486CB4DC...@ruby-lang.org>,
Urabe Shyouhei <shyo...@ruby-lang.org> writes:

> Thank you, I merged this revision into 1.8.7.

It causes following problem.

% ./ruby -rsingleton -ve '
class C
include Singleton
end
m = Marshal.dump(C.instance)
p Marshal.load(m)
'
ruby 1.8.6 (2008-07-02 patchlevel 264) [i686-linux]
-e:6:in `load': class C needs to have method `_load' (TypeError)
from -e:6

r16659 is also required.

Note that r16659 causes RubySpec failure, it is another
RubySpec bug.
--
Tanaka Akira

schreibe...@googlemail.com

unread,
Jul 3, 2008, 8:39:12 AM7/3/08
to ruby...@ruby-lang.org
Hello Urabe, hello Tanaka,

That problem seems to only exist in 1.8.6, r16659 seems to have been
merged into 1.8.7 already.

Thank you, Arthur

On 3 Jul., 13:56, Tanaka Akira <a...@fsij.org> wrote:
> In article <486CB4DC.4030...@ruby-lang.org>,

Tanaka Akira

unread,
Jul 3, 2008, 8:44:08 AM7/3/08
to ruby...@ruby-lang.org
In article <0347cecd-a275-4022...@79g2000hsk.googlegroups.com>,
"schreibe...@googlemail.com" <schreibe...@googlemail.com> writes:

> That problem seems to only exist in 1.8.6, r16659 seems to have been
> merged into 1.8.7 already.

You are right. r16659 is for 1.8.6.
--
Tanaka Akira

Charles Oliver Nutter

unread,
Jul 3, 2008, 9:21:05 AM7/3/08
to ruby...@ruby-lang.org

Others have already responded, but I think it's of paramount importance
that any release pass the tests it's expected to pass. So then the
question becomes whether ruby-core has decided that 1.8.x releases are
expected to pass rubyspec. I think the community would like very much
for that to be the case.

- Charlie

Igal Koshevoy

unread,
Jul 3, 2008, 9:37:09 AM7/3/08
to ruby...@ruby-lang.org
Urabe Shyouhei wrote:
> Charles Oliver Nutter wrote:
>
>> There should not be a release until the failures in rubyspec are
>> addressed.
>>
>
> OK, so all of you can wait until rubyspec passes? I think I cannot
> review every failures in a 24 hours so releases should be delayed. Is it
> really OK?
>
Please delay the release. I don't think we'll be able to resolve the
remaining critical issues by Friday.

There's a definite, consistently reproducable memory leak[1] in both
p230 and p238, and likely in HEAD. This memory leak is a show-stopper
and will make it impossible for anyone running Rails or other
long-running processes to use these versions. There are also a number of
other problems that the RubySpec has identified, some of which seem severe.

What is the SVN URL for the current release candidate that we should be
testing? I was checking r17631 of the ruby_1_8_6 branch, which calls
itself p238.

I realize you and the other maintainers have been under a lot of strain
recently, but I sincerely appreciate you working through this with us.
Thank you.

-igal

[1] http://redmine.ruby-lang.org/issues/show/216

Charles Oliver Nutter

unread,
Jul 3, 2008, 9:49:41 AM7/3/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:
> Please delay the release. I don't think we'll be able to resolve the
> remaining critical issues by Friday.

For what it's worth, this is all a strong argument for having a CI
server and keeping rubyspec "green" all the time. Nobody likes having to
delay a release because there's a stack of errors to be dealt with.

- Charlie

Igal Koshevoy

unread,
Jul 3, 2008, 10:21:47 AM7/3/08
to ruby...@ruby-lang.org
Absolutely.

Is anyone providing CI for Ruby releases? Is there a good CI tool
written in Ruby? Would Hudson be acceptable for doing Ruby stuff? Is
JRuby or one of the other alternative implementations using something
for CI that they're happy with?

I've been building up a shell script, mostly for personal use, so I can
run the checks against various test suites. I attached an earlier
version with my bug report #199 asking for patch reviews. I can mop that
script up a bit and release versions so that others can run the full
suite of tests on-demand from their command line and or from a CI
server. I've been building this as a shell script because it minimizes
dependencies so that as long as the user has bash, svn, git, wget, tar
and maybe a tiny number of other utilities, they can run it. Does this
sound useful?

I also talked earlier about setting up a bunch of VMs running different
OSes and running the test scripts against these, which would be a good
way to catch platform-specific issues. Is there interest in such a thing?

However, if someone's already done this effort, it'd be good to know so
we can take a look at it and possibly build upon it instead.

-igal

Phlip

unread,
Jul 3, 2008, 11:03:24 AM7/3/08
to ruby...@ruby-lang.org
Igal Koshevoy wrote:

> Is anyone providing CI for Ruby releases? Is there a good CI tool
> written in Ruby?

CruiseControl.rb doesn't suck.

(Parenthetically, here's a tweak to draw charts of statistics over time with it:
http://www.oreillynet.com/ruby/blog/2008/03/cruisecontrol_charts.html )

--
Phlip

Wilson Bilkovich

unread,
Jul 3, 2008, 11:07:44 AM7/3/08
to ruby...@ruby-lang.org

Ryan Davis is working on a system for this right now. Last I heard, it
is nearing completion.

Igal Koshevoy

unread,
Jul 3, 2008, 11:21:47 AM7/3/08
to ruby...@ruby-lang.org
Phlip wrote:
> Igal Koshevoy wrote:
>
>> Is anyone providing CI for Ruby releases? Is there a good CI tool
>> written in Ruby?
>
> CruiseControl.rb doesn't suck.
Great, thanks for the recommendation. The manual
[http://cruisecontrolrb.thoughtworks.com/documentation/manual] describes
the product in a fairly sensible manner. Seems like it can run anything
that you can point a Rake task at, so it's quite flexible. Their demo
[http://cruisecontrolrb.thoughtworks.com/projects] gives a pretty good
idea of what the tool does too.

> (Parenthetically, here's a tweak to draw charts of statistics over
> time with it:
> http://www.oreillynet.com/ruby/blog/2008/03/cruisecontrol_charts.html )

Thanks for writing that up. :)

-igal

M. Edward (Ed) Borasky

unread,
Jul 3, 2008, 1:32:04 PM7/3/08
to ruby...@ruby-lang.org

Glad to hear it. I've got some spare cycles (day job starts again 8
July.) :) I was about to start up on this, but if someone is doing it,
I'll wait. My own thinking was to do

1. Check out Ruby 1.8.6 from SVN.
2. Compile with GCC 4.3.1 with the "gcov" coverage analysis and debug
options. I only have an AMD64 dual-core and 4 GB of RAM running Gentoo
Linux, not a buncha VMs with every conceivable environment. For other
environmental reasons, I compile *with* threads.
3. Run all the test suites and benchmark suites (someday, we really
should merge those.) :)
4. Post the code coverage analysis, test suite results, and tracebacks
for any crashes "somewhere". I've got "oprofile" working, so I can also
post profiles if anyone cares.

I'm definitely going to do the benchmarks; this started out as a
profiling exercise on Rubinius. :) A Rakefile would be nice, but I am a
terrible Rakefile writer -- for some reason, I can't do "DRY" Rakefiles.
I usually end up just defining a whole bunch of Ruby methods to make a
sensibly factored set of code, which seems somehow "un-Rake-like." :)

M. Edward (Ed) Borasky

unread,
Jul 3, 2008, 1:35:16