Using -v somehow makes test-all on osx stable. Let me check if travis_wait
solves the issue or not.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66501 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Reduce thread counts unconditionally for some CI systems with
low limits.. And Solaris apparently lacks RLIMIT_NPROC, so we
can't detect resource limits and scale the test appropriately.
[ruby-core:90670] [Bug #15430]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66494 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The true bug fork_gen was hiding was rb_mutex_abandon_locking_mutex
failing to unconditionally clear the waitq of mutexes it was
waiting on. So we fix rb_mutex_abandon_locking_mutex, instead,
and eliminate rb_mutex_cleanup_keeping_mutexes.
This commit was tested heavily on a single-core Pentium-M which
was my most reliable reproducer of the "crash.rb" script from
[Bug #15383]
[Bug #14578] [Bug #15383]
Note: [Bug #15430] turned out to be an entirely different
problem: RLIMIT_NPROC limit was hit on the CI VMs.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66489 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Even building ruby seems to hang for unknown reasons.
https://travis-ci.org/ruby/ruby/jobs/471021727
Travis's osx environment is too fragile. Avoid anything dangerous.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66484 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
osx build has failed too often. we don't know why.
To know which test hangs forever, we might want to have hard timeout for
all test case (like 9min, slightly less than no-output timeout) in test-all.
But it's a little hard to implement and I would workaround an unknown
cause somehow.
It's known that -j is harmful for some tests in test-all. Let's try to
remove it first, and if it doesn't work, I'll resurrect -v option to
easily know which test is the culprit.
Slow correctness is much better than fast false-positive.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66482 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The tests are really fragile with --jit-wait and it doesn't have interface
to modify this timeout at all.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66480 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Reject ArithmeticSequence in rb_range_values so that methods like
Array#[] raises TypeError for ArithmeticSequence as an index.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66478 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
... when clearing waitq. Otherwise, we risk redundantly clearing
valid waiters in future calls to `mutex_ptr`.
Note: I am not sure if this fixes [Bug #15430], and even if it
did, fork_gen is a belt-and-suspenders redundancy for [Bug #15383]
which wastes one word for every Mutex object.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66477 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
rb_mutex_abandon_all functions fine when passed a NULL value,
so let the compiler deal with the complexity of the branch
instead of the person reading the code.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66476 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Fix the wrong uses of rb_int_ge in arith_seq_each.
[ruby-core:90648] [Bug #15444]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66474 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It wrongly used all linenos of ISeq#trace_points which includes not only
line events but also call, return, and other events. So, the result
included some linenos that can not be covered at all by line coverage.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66468 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Previously, these hash literals were not frozen, and thus could be
modified by ObjectSpace, resulting in undesired behavior. Example:
```ruby
require 'objspace'
def a(b={0=>1,1=>4,2=>17})
b
end
p a
ObjectSpace.each_object(Hash) do |a|
a[3] = 8 if a.class == Hash && a[0] == 1 && a[1] == 4 && a[2] == 17
end
p a
```
It may be desirable to hide such hashes from ObjectSpace, since
they are internal, but I'm not sure how to do that.
From: Jeremy Evans <code@jeremyevans.net>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66464 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* tool/rbinstall.rb (load_gemspec): do not hide syntax errors in
a gemspec file. check if the result instead.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66460 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The following race may happen if ubf_timer_destroy calls
timer_delete before ubf_timer_disarm gets called from
a different thread. Consider the following timelines:
ubf_timer_destroy | ubf_timer_disarm
-------------------------------------+-----------------------------
| CAS(ARM => DISARM)
CAS(DISARM => DEAD) |
timer_delete |
| timer_settime(disarm)
Another option may be to add an intermediate "RTIMER_DISARMING"
state to the transition, but I figure the EINVAL check is
simpler and less intrusive code-wise.
cf. http://ci.rvm.jp/results/trunk-iseq_binary@silicon-docker/1545794
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66457 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
So that a customized HTTPServer subclass can use it's own
Request/Response classes.
To apply the override, make a subclass of WEBrick::HTTPServer
and override the
`create_request_and_response(with_webrick_config)` method. The
method should return an Array of [request, response].
To check whether the Server supports this method (i.e. when
using older versions of WEBrick when needing this
functionality), you can ask the server if it responds to the
method
server.respond_to?(:create_request_and_response)
This is backportable.
[ruby-core:69604] [Feature #11266]
From: Julik Tarkhanov <me@julik.nl>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66452 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
