| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
With travis_wait, we may not need -j3 for test-all anymore, but still we
need to avoid hanging on building Ruby somehow.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66504 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
| |
We're hitting `Expected |200 - 351| (151) to be <= 150.` in several places:
https://rubyci.org/logs/rubyci.s3.amazonaws.com/osx1012/ruby-trunk/log/20181215T094505Z.fail.html.gz
https://travis-ci.org/ruby/ruby/jobs/471483171
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66503 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
because travis_wait is not found via setarch
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66502 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
detected by coverity scan
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66500 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
| |
It fixed the issues of RubyGems 3.0.0.
https://blog.rubygems.org/2018/12/23/3.0.1-released.html
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66499 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
| |
From: Victor Shepelev <zverok.offline@gmail.com>
[ruby-core:90673] [Bug #15452]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66498 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66497 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
Patch by Shuji Kobayashi.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66496 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66495 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
|
|
|
|
|
|
|
| |
* eval_error.c (show_cause): get rid of infinite recursion on
circular causes. [Bug #15447]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66493 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66492 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66491 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
https://github.com/ruby/ruby/commit/3efcb74036af32cbcc889d06d8c6c546289e89f4#r31762996
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66490 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
|
|
|
|
|
|
|
|
|
|
| |
Perhaps this error report is down to resource limits on a VM:
http://rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181221T230003Z.fail.html.gz
But rb_mutex_t.fork_gen is still redundant, I think.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66488 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
|
| |
I can't find stderr in the test-all output of the CI machine,
so maybe the assertion will show what's going on.
http://rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181221T170003Z.log.html.gz#test-all
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66487 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66486 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66485 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
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66483 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
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66481 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
|
|
|
|
|
|
|
| |
to investigate
https://rubyci.org/logs/rubyci.s3.amazonaws.com/unstable11s/ruby-trunk/log/20181221T092505Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66479 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
|
|
|
|
|
|
| |
Fixes [Bug #15447]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66475 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
|
|
|
|
|
|
| |
* https://github.com/ruby/bigdecimal/compare/v1.4.0.pre.20181214a..v1.4.0.pre.20181220a
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66473 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66472 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66471 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66470 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
| |
[Fix GH-2052]
From: Jon Burgess <jkburges@gmail.com>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66469 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
|
|
|
|
|
|
| |
copy from README.md
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66467 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
|
|
| |
* compile.c (compile_array): hide source Hash object.
* hash.c (rb_hash_resurrect): introduced to dup Hash object
using rb_cHash.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66466 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66465 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
|
|
|
|
|
|
|
|
| |
* parse.y (reg_named_capture_assign_iter): ignore non-local name
captures, including non-ASCII constant names.
[ruby-dev:50719] [Bug #15437]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66463 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66462 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
| |
[Bug #13423]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66461 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
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66459 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
|
|
|
|
|
| |
See https://github.com/ruby/rexml/blob/master/NEWS.md for change summary.
Changes for spec/ has been reported: https://github.com/ruby/spec/pull/639
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66458 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
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66456 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|
|
|
|
| |
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66455 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
|