On btest, stderr messages are not displayed if core files are
generated. There is no reason to skip it, so this patch display
stderr and check core files.
This changes the following warnings:
* warning: class variable access from toplevel
* warning: class variable @foo of D is overtaken by C
into RuntimeErrors. Handle defined?(@@foo) at toplevel
by returning nil instead of raising an exception (the previous
behavior warned before returning nil when defined? was used).
Refactor the specs to avoid the warnings even in older versions.
The specs were checking for the warnings, but the purpose of
the related specs as evidenced from their description is to
test for behavior, not for warnings.
Fixes [Bug #14541]
rb_uninterruptible() disables any interrupts using handle_interrupt
feature (This function is used by `p`).
After this function, pending interrupts should be checked correctly,
however there is no chance to setup interrupt flag of working
threads, it means that nobody checks pending interrupts.
For example, it ignores terminate signal delivered at the end
of main thread and program can't stop.
This patch set interrupt flag if there are pending interrupts.
On Deiban 9 environment, the thread tests failed and
this maximum threads information can finish up the machine
resources. To check it, I turned-off showing this information.
This behavior was deprecated in 2.7 and scheduled to be removed
in 3.0.
Calling yield in a class definition outside a method is now a
SyntaxError instead of a LocalJumpError, as well.
This changes object_id from being based on the objects location in
memory (or a nearby memory location in the case of a conflict) to be
based on an always increasing number.
This number is a Ruby Integer which allows it to overflow the size of a
pointer without issue (very unlikely to happen in real programs
especially on 64-bit, but a nice guarantee).
This changes obj_to_id_tbl and id_to_obj_tbl to both be maps of Ruby
objects to Ruby objects (previously they were Ruby object to C integer)
which simplifies updating them after compaction as we can run them
through gc_update_table_refs.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
This changes object_id from being based on the objects location in
memory (or a nearby memory location in the case of a conflict) to be
based on an always increasing number.
This number is a Ruby Integer which allows it to overflow the size of a
pointer without issue (very unlikely to happen in real programs
especially on 64-bit, but a nice guarantee).
This changes obj_to_id_tbl and id_to_obj_tbl to both be maps of Ruby
objects to Ruby objects (previously they were Ruby object to C integer)
which simplifies updating them after compaction as we can run them
through gc_update_table_refs.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
In addition to detect dead canary, we try to detect the very moment
when we smash the stack top. Requested by k0kubun:
https://twitter.com/k0kubun/status/1085180749899194368
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66981 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* bootstraptest/runner.rb (assert_normal_exit): check MJIT first
to support btest with ruby ~2.5. btest (bootstraptest) should be
enable to run with stable ruby interpreter because modified ruby
may not able to run runner.rb and we need to know why (this is why
we introduce btest).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66842 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
"hash_bulk_insert" first expands the table, but the target size was
wrong: it was calculated by "num_entries + (size to buld insert)", but
it was wrong when "num_entries < entries_bound", i.e., it has a deleted
entry. "hash_bulk_insert" adds the given entries from entries_bound,
which led to out-of-bounds write access. [Bug #15536]
As a simple fix, this commit changes the calculation to "entries_bound +
size". I'm afraid if this might be inefficient, but I think it is safe
anyway.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66832 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
because test_io.rb:33 randomly fails
http://ci.rvm.jp/results/trunk-mjit-wait@silicon-docker/1519055
checking MJIT.enabled? on driver might not make sense for target, but as
long as the CI is -DMJIT_FORCE_ENABLE, I believe it works for now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66344 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (env_enc_str_new): as no locale/filesystem encoding is
available in miniruby on Windows, fallback the encoding to
ASCII-8BIT so it is valid encoding when the conversion failed.
[ruby-core:89177] [Bug #15164]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64860 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Resurrect r63754 in a 1.8-compatible way. While we're at it,
add a note to maintain 1.8 compatibility (cf. r63757).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64120 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Koichi Sasada
Takashi Kokubun
Jeremy Evans
Nobuyoshi Nakada
John Hawthorn
Aaron Patterson
卜部昌平
Kazuhiro NISHIYAMA
Samuel Williams
git
nobu
shyouhei
naruse
ko1
mame
k0kubun
usa
kazu
normal