Re-revert r64340, and take care about notimplemented case.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64343 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Module has many introspection methods for methods and constants that
either return an array or return true or false for whether the method
or constant is defined. Most of these methods support an optional
argument that controls whether to consider inheritance. Currently,
the following Module methods support such a argument:
* const_defined?
* constants
* instance_methods
* private_instance_methods
* protected_instance_methods
* public_instance_methods
and the following methods do not:
* method_defined?
* private_method_defined?
* protected_method_defined?
* public_method_defined?
This patch supports such an argument for the *method_defined?
methods.
While you can currently work around the lack of support via:
mod.instance_methods(false).include?(:method_name)
This patch allows the simpler and more efficient:
mod.method_defined?(:method_name, false)
One case where you want to exclude inheritance when checking
for a method definition is when you want to replace a method
that may already exist. To avoid a verbose warning, you want
to remove the method only if it is already defined:
remove_method(:foo) if method_defined?(:foo, false)
define_method(:foo){}
You can't call remove_method without checking for the method
definition, as that can raise a NameError, and you don't want
to include inheritance because remove_method will still raise
a NameError if the method is defined by an ancestor and not
by the module itself.
[ruby-core:88140] [Feature #14944]
From: Jeremy Evans <code@jeremyevans.net>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64337 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* test/ruby/test_env.rb (test_huge_value): Windows 8 seems having a
limit on single environment variable.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64303 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
failure. It's failing on mswinci but it's hard to know the cause without
out/err.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64299 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We should increase RUBY_TEST_SUBPROCESS_TIMEOUT_SCALE for slow
environments, and we configured some CI machines.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64295 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (ruby_setenv): do not check environment block size.
c.f. https://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
Starting with Windows Vista and Windows Server 2008, there is no
technical limitation on the size of the environment block.
[ruby-core:88400] [Bug #14979]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64293 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
to fix the wrong line number on #caller_locations or rb_profile_frames.
Actually we would be able to move it only when method call (of
caller_locations) or C extension invocation (calling rb_profile_frames)
can happen.
This degrades performance. Optcarrot fps becomes...
before: 71.78976052783555
after: 67.65429356624131
I think I can lazily move it and fix the performance issue, even
improving the performance for the situation catch table exists.
But let me fix this bug first...
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64283 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It's timed out on CI like this
https://gist.github.com/ko1/33df53d78fbec9e4156c017eeae023bb.
I'm not sure how long it would take (it finishes immediately on my machine),
so I chose 600s because r64271 says it took 635s on mswinci. (probably
it's improved by the commit, though.)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64278 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It takes 635 seconds on mswinci
20180810T061315Z.log.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64271 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This fixes a bug of Enumerator::ArithmeticSequence#last in the case that
a non-integral argument is passed.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64262 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Undefine new and allocate methods of Enumerator::ArithmeticSequence.
[ruby-core:82816] [Feature #13904]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64256 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Due to a bug in OpenSSL 1.1.0h[1] (it's only in this specific version;
it was introduced just before the release and is already fixed in their
stable branch), the callback set by SSLContext#session_new_cb= does not
get called for clients, making net/http and net/ftp not attempt session
resumption.
Let's disable the affected test cases for now. Another option would be
to fallback to using SSLSocket#session as we did before r64234. But
since only a single version is affected and hopefully a new stable
version containing the fix will be released in near future, I chose not
to add such workaround code to lib/.
[1] https://github.com/openssl/openssl/pull/5967
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64252 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
and wait until JIT queue is flushed when wait option is not passed or
`wait: true` is passed.
vm.c: ditto
test/ruby/test_rubyvm_mjit.rb: added test for pause/resume
test/lib/jit_support.rb: allow retrying MJIT on JITSupport level
test/ruby/test_jit.rb: ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64250 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Running with TESTS=--no-retry, I sometimes get short reads
leading to failures due to the use of IO#readpartial instead of
IO#gets.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64248 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Apparently my tty can't keep up when I run test-all with
TESTS='-v --no-retry'
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64247 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* io.c (argf_next_argv): convert filename to the OS encoding to be
dealt with by system calls. [ruby-dev:50607] [Bug #14970]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64243 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Quiet a false-positive warning from TestHtgroup#test_htgroup
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64238 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
When TLS 1.3 is in use, the session ticket may not have been sent yet
even though a handshake has finished. Also, the ticket could change if
multiple session ticket messages are sent by the server. Use
SSLContext#session_new_cb instead of calling SSLSocket#session
immediately after a handshake. This way also works with earlier protocol
versions.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64234 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Sync with the current tip of master branch, 62436385306c of
ruby/openssl.git. Changes can be found at:
https://github.com/ruby/openssl/compare/v2.1.1...62436385306c
----------------------------------------------------------------
Brian Cunnie (1):
Correctly verify abbreviated IPv6 SANs
Janko Marohnić (1):
Reduce memory allocation when writing to SSLSocket
Jeremy Evans (1):
Move rb_global_variable call to directly after assignment
Kazuki Yamaguchi (7):
pkcs7: allow recipient's certificate to be omitted for PKCS7#decrypt
pkey: resume key generation after interrupt
tool/ruby-openssl-docker: update to latest versions
test/test_ssl: fix test failure with TLS 1.3
test/test_x509name: change script encoding to ASCII-8BIT
x509name: refactor OpenSSL::X509::Name#to_s
x509name: fix handling of X509_NAME_{oneline,print_ex}() return value
ahadc (1):
Update CONTRIBUTING.md
nobu (6):
no ID cache in Init functions
search winsock libraries explicitly
openssl: search winsock
openssl_missing.h: constified
reduce LibreSSL warnings
openssl/buffering.rb: no RS when output
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64233 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
By this commit's changes in other files, now MJIT started to work on VC++.
Unfortunately some features are still broken and they'll be fixed later.
This also suppresses cl.exe's default output to stdout because there
seems to be no option to do it. Tweaking some log messages as well.
vm_core.h: declare `__declspec(dllimport)` to export them correctly on mswin.
vm_insnhelper.h: ditto
mjit.h: ditto
test_jit.rb: skipped some pending tests.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64221 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This commit introduces new core class Enumerator::ArithmeticSequence.
Enumerator::ArithmeticSequence is a subclass of Enumerator, and
represents a number generator of an arithmetic sequence.
After this commit, Numeric#step and Range#step without blocks
returned an ArithmeticSequence object instead of an Enumerator.
This class introduces the following incompatibilities:
- You can create a zero-step ArithmeticSequence,
and its size is not ArgumentError, but Infinity.
- You can create a negative-step ArithmeticSequence from a range.
[ruby-core:82816] [Feature #13904]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64205 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Unfortunately, MJIT goes over the 100M RLIMIT_AS for this test
on x86-64 (Debian 9)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64204 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Trying to diagnose CI failures from i686-linux on Debian 7.
This also fixes a potential GC problem with Thread.start or
IO#read potentially closing the write-end of the pipe due
to allocation.
cf. 20180805T080500Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64199 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
MJIT way generate an extra SIGCHLD, so we'll have to deal with it.
Any realistic Ruby program may hit unexpected SIGCHLD, too,
since any spawned subprocess could have extra grandchildren
which get reaped by the main Ruby process, and SIGCHLD may
be sent spuriously by an external process using kill(2) syscall
(via kill(1) or Process.kill).
cf. http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1194620
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64194 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We can reuse the sub-thread and exception with Thread#raise to
reproduce the old memory leak with less overhead. This allows
us to to run more iterations and improve reliability of the
actual test, particularly on platforms without USE_THREAD_CACHE.
For glibc and jemalloc, also limit arena count to avoid
inadvertant growth.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64187 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Use Thread.pass to let the sub-thread finish. This should avoid
running out of memory on resource-constrained systems.
(We don't want to use Thread#join to hit the exception)
This results in a significant memory usage reduction in this test:
make test-all TESTS='../test/ruby/test_thread.rb -v -n test_thread_interrupt_for_killed_thread'
Before:
3.46user 2.02system 0:05.29elapsed 103%CPU (0avgtext+0avgdata 88672maxresident)k
0inputs+0outputs (0major+143071minor)pagefaults 0swaps
After:
3.40user 1.83system 0:05.20elapsed 100%CPU (0avgtext+0avgdata 9368maxresident)k
0inputs+0outputs (0major+3059minor)pagefaults 0swaps
cf. 20180803T231706Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64186 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Still looking into CI failures on P895 (and seemingly no other boxes):
http://ci.rvm.jp/results/trunk@P895/1190369
:<
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64184 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* ast.c (Init_ast): undefine allocator of Node, as a method call
on an uninitialized Node causes segfault.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64168 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Actually unload_units is working on MinGW, but putiseq is behaving
badly.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64163 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It looks like we need to retry test_timestampns in addition
to test_timestamp; so share some code while we're at it.
cf. http://ci.rvm.jp/results/trunk-test@frontier/1153126
[ruby-core:88104] [Bug #14898]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64157 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
when $MJIT_SEARCH_BUILD_DIR is set.
If prefix path is owned by root, `make install` needs to be run by root.
But in general we don't want to run `make test-all`, and also running
`make test-all` currently fails due to permission tests of rdoc and rubygems.
Thus, prior to this commit, specifying a prefix like "/usr/local" could
mean there was no way to pass test-all.
So we should not depend on `make install` for `make test-all`. Thus I
reverted r64104 and r64103, and applied this workaround to pass `make
test-all` without `make install`.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64143 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* test/ruby/test_thread_{cv,queue}.rb: Move under the test/ruby directory.
and rename TestThread* from Test*.
* test/test_sync.rb: Move toplevel of test diretory because sync is still
standard library.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64137 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I can't reproduce the test failure and I'm still not sure what's
wrong, but maybe we can get a core dump from P895:
http://ci.rvm.jp/results/trunk@P895/1174672
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64135 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
To reduce resource use and reduce CI failure; remove
timer-thread. Single-threaded Ruby processes (including forked
children) will never see extra thread overhead. This prevents
glibc and jemalloc from going into multi-threaded mode and
initializing locks or causing fragmentation via arena explosion.
The GVL is implements its own wait-queue as a ccan/list to
permit controlling wakeup order. Timeslice under contention is
handled by a designated timer thread (similar to choosing a
"patrol_thread" for current deadlock checking).
There is only one self-pipe, now, as wakeups for timeslice are
done independently using condition variables. This reduces FD
pressure slightly.
Signal handling is handled directly by a Ruby Thread (instead
of timer-thread) by exposing signal self-pipe to callers of
rb_thread_fd_select, native_sleep, rb_wait_for_single_fd, etc...
Acquiring, using, and releasing the self-pipe is exposed via 4
new internal functions:
1) rb_sigwait_fd_get - exclusively acquire timer_thread_pipe.normal[0]
2) rb_sigwait_fd_sleep - sleep and wait for signal (and no other FDs)
3) rb_sigwait_fd_put - release acquired result from rb_sigwait_fd_get
4) rb_sigwait_fd_migrate - migrate signal handling to another thread
after calling rb_sigwait_fd_put.
rb_sigwait_fd_migrate is necessary for waitpid callers because
only one thread can wait on self-pipe at a time, otherwise a
deadlock will occur if threads fight over the self-pipe.
TRAP_INTERRUPT_MASK is now set for the main thread directly in
signal handler via rb_thread_wakeup_timer_thread.
Originally, I wanted to use POSIX timers
(timer_create/timer_settime) for this. Unfortunately, this
proved unfeasible as Mutex#sleep resumes on spurious wakeups and
test/thread/test_cv.rb::test_condvar_timed_wait failed. Using
pthread_sigmask to mask out SIGVTALRM fixed that test, but
test/fiddle/test_function.rb::test_nogvl_poll proved there'd be
some unavoidable (and frequent) incompatibilities from that
approach.
Finally, this allows us to drop thread_destruct_lock and
interrupt current ec directly.
We don't need to rely on vm->thread_destruct_lock or a coherent
vm->running_thread on any platform. Separate timer-thread for
time slice and signal handling is relegated to thread_win32.c,
now.
[ruby-core:88088] [Misc #14937]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64107 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This should fix CI failure under MJIT, 100ms wait may not be
enough for signal handler to fire:
http://ci.rvm.jp/results/trunk-mjit@silicon-docker/1169472
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64105 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
for the ease of MSP-Greg's CI. I'll track this failure as Bug#14948 and
fix it later.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64099 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
