Remove the remainder of ROOT_FIBER_CONTEXT use and unnecessary
differences between the root and non-root fiber. This makes
it easier to follow new root fiber at fork time.
Multiple sources of truth often leads to bugs, as in this case.
We can determinte root fiber by checking a fiber against the root_fiber
of its owner thread. The new `fiber_is_root_p' function
supports that.
Now, we can care only about free-ing/recycling/munmap-ing stacks
as appropriate.
[Bug #15050]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64706 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Make sure Enumerator::ArithmeticSequence#each to work well
for a complex step value.
This reverts commit ca47fb329a.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64695 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Make sure Enumerator::ArithmeticSequence#each to work well
for a complex step value.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64692 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* range.c (range_cover): add code for range argument.
If the argument is a Range, check it is or is not
covered by the reciver. If it can be treated as a
sequence, this method treats it that way.
* test/ruby/test_range.rb (class TestRange): add tests
for this feature.
This patch is written by Owen Stephens. thank you!
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64640 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Interrupt timing is tricky and it's possible the target
thread is still stopped from the previous loop iteration.
[ruby-core:88732] [Bug #15043]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64590 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Otherwise, th->root_fiber can point to an invalid Fiber,
because Fibers do not live across fork. So consider
whatever Fiber is running the root fiber.
[ruby-core:88723] [Bug #15041]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64589 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Arch Linux CI still seems to timeout on this test...
Note, I can't reproduce the failures in these tests on a
FreeBSD 11.1 VM while infinite-looping, even without the
"th.join(0.001)". It doesn't seem related to the use of
rb_wait_for_single_fd (r64529).
cf. 20180826T090003Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64543 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Too many machines lack entropy to have a usable /dev/random. I
had similar problems on my system until I started using
haveged(8), but we can't require that for CI.
cf. 20180825T213003Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64540 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We need to ensure Signal.trap handlers can function if the main
thread is sleeping after a subthread has grabbed sigwait_fd,
but later exited.
Consider the following timeline:
main_thread sub-thread
-----------------------------------------
Signal.trap() { ... }
get sigwait_fd
ppoll on sigwait_fd
native_cond_sleep
(via pthread_cond_wait)
ppoll times-out
put sigwait_fd
sub-thread exits
only thread alive
SIGNAL HITS
The problem is pthread_cond_wait cannot return EINTR,
so we can never run the Signal.trap handler. So we
will avoid using native_cond_sleep in the main thread
and always use ppoll to sleep when in the main thread.
This can guarantee the main thread remains aware of
signals; even if it cannot safely read off sigwait_fd
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64538 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
IO#sysread calls rb_wait_for_single_fd for compatibility, and
perhaps something is amiss with that (unrelated to timer-thread
elimination)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64529 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* iseq.c (iseq_init_trace): at ISeq loading time, we need to check
`ruby_vm_event_enabled_flags` to turn on trace instructions.
Seprate this checking code from `finish_iseq_build()` and make
new function. `iseq_ibf_load()` calls this funcation after loading.
* test/ruby/test_iseq.rb: add a test for this fix.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64514 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Line coverage was based on special instruction "tracecoverage".
Now, instead, it uses the mechanism of trace hook [Feature #14104].
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64509 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The code fragments that initializes coverage data were scattered into
both parse.y and compile.c. parse.y allocated a coverage data, and
compile.c initialize the data.
To remove this cross-cutting concern, this change moves the allocation
from "coverage" function of parse.y to "rb_iseq_new_top" of iseq.c.
For the sake, parse.y just counts the line number of the original source
code, and the number is passed via rb_ast_body_t.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64508 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
CI failures are still happening from these tests, but try
to break out of it earlier instead of holding up the job.
[Bug #14898]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64484 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
According to some runs in mjit-test (make test-all RUN_OPTS="--jit-wait"),
this test might not be the cause of its failure.
So, let me try running this again.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64426 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Arbitrarily closing file descriptors on exec breaks use cases
where a Ruby process sets up a descriptor for non-Ruby children
to use. For example, the "rake foo" target may spawn any number
of subprocesses (Ruby or not) which depends on parsing the "FOO"
environment variable for out_fd:99 and writing to foo.out
FOO=out_fd:99 rake foo 99>>foo.out
Unfortunately, this introduced one incompatibility in
test/lib/test/unit.rb and it now requires explicitly setting
IO#close_on_exec=true
[ruby-core:88007] [Misc #14907]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64399 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It is possible for Mutex#sleep (via ConditionVariable#wait)
to prematurely wake up under MJIT (because Mutex#sleep can't
handle spurious wakeups). This affects @idle_done_cond in
Net::IMAP#idle and means the response handler may never
set `in_idle' to `true`.
In any case, ensure the infinite looping `raiser' thread
stops running when the test is done.
Will work on reducing the effect of spurious wakeups from
MJIT...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64387 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I still seem to need more memory for parallel tests with MJIT...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64381 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
that times out with test-all w/ --jit-wait.
I'm running the following command on Wecker CI everyday:
```
make test-all TESTOPTS="--color=never --job-status=normal" RUN_OPTS="--disable-gems --jit-wait --jit-warnings" RUBY_FORCE_TEST_JIT=1
```
By running yesterday's all commits, r64354 ran successfully but r64355
didn't. So the test should be fixed to run with --jit-wait at first.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64374 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Let me skip this to make CI green first and take a look later...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64365 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This reverts commit 52102f6ff5 (r64238).
It is no longer necessary if we use Tempfile.create in
WEBrick::HTTPAuth::Htgroup#flush (see next commit)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64362 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
EINTR seems unavoidable in real programs (or MJIT), so maybe
it's not worth dealing with. r64353 relies on POSIX timers
to signal.
Switching pipes and sockets to non-blocking by default would let
us get rid of POSIX timers, timer pthread and this hack:
https://bugs.ruby-lang.org/issues/14968
[ruby-core:88360] [Misc #14937]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64355 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This reverts commit 194a6a2c68 (r64203).
Race conditions which caused the original reversion will be fixed
in the subsequent commit.
[ruby-core:88360] [Misc #14937]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64352 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
