| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
to fix
https://ci.appveyor.com/project/ruby/ruby/builds/24438615/job/yld1utsltxag9dr2
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up for 3f9562015e651735bfc2fdd14e8f6963b673e22a.
Before this commit, it was possible to create a shared string which
shares with another shared string by passing a frozen shared string
to `str_duplicate`.
Such string looks like:
```
-------- -----------------
| root | ------ owns -----> | root's buffer |
-------- -----------------
^ ^ ^
----------- | |
| shared1 | ------ references ----- |
----------- |
^ |
----------- |
| shared2 | ------ references ---------
-----------
```
This is bad news because `rb_fstring(shared2)` can make `shared1`
independent, which severs the reference from `shared1` to `root`:
```c
/* from fstr_update_callback() */
str = str_new_frozen(rb_cString, shared2); /* can return shared1 */
if (STR_SHARED_P(str)) { /* shared1 is also a shared string */
str_make_independent(str); /* no frozen check */
}
```
If `shared1` was the only reference to `root`, then `root` can be
reclaimed by the GC, leaving `shared2` in a corrupted state:
```
----------- --------------------
| shared1 | -------- owns --------> | shared1's buffer |
----------- --------------------
^
|
----------- -------------------------
| shared2 | ------ references ----> | root's buffer (freed) |
----------- -------------------------
```
Here is a reproduction script for the situation this commit fixes.
```ruby
a = ('a' * 24).strip.freeze.strip
-a
p a
4.times { GC.start }
p a
```
- string.c (str_duplicate): always share with the root string when
the original is a shared string.
- test_rb_str_dup.rb: specifically test `rb_str_dup` to make
sure it does not try to share with a shared string.
[Bug #15792]
Closes: https://github.com/ruby/ruby/pull/2159
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Objects in the finalizer table stay pinned for now. In some cases, the
key could move which would cause a miss when removing the object from
the table (leading to a T_MOVED reference staying in the table).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`obj_info` will look at references of objects in some cases (for example
it will try to access path information on ISeq objects). But during the
sweep phase, if the referenced object is collected before `obj_info` is
called, then it could be a bad ref and a segv will occur.
For example:
A -> B
Sweep phase:
1. obj_info(B)
2. Sweep and free B
3. obj_info(A); A tries to read B
4. SEGV
This commit simply removes the call to `obj_info` during the sweep
phase.
|
|
|
|
|
|
| |
to prevent failure like
https://app.wercker.com/ruby/ruby/runs/mjit-test1/5cd28aa6ab79a30008ee819b?step=5cd28b2403f44600070db083
with --jit-verbose=1.
|
| |
|
|
|
|
| |
[EXPERIMENTAL]
|
| |
|
|
|
|
|
| |
see r67347
recent log: https://travis-ci.org/ruby/ruby/jobs/529640417
|
| |
|
|
|
|
|
|
| |
for debugging failure like
https://app.wercker.com/ruby/ruby/runs/mjit-test1/5cc98936ab79a30008eb86fa?step=5cc990d73d81fb0007bb04c3
https://app.wercker.com/ruby/ruby/runs/mjit-test1/5cd18efa23fcb70008ddfd45?step=5cd1908603f4460007076c5a
|
| |
|
|
|
|
| |
Fixing 7d805e67f3275aef066d77aa9c32bef715c362ed
|
|
|
|
| |
Recently `ruby/spec on Ruby 2.4` seems stable.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
pattern matches are less than or equal to 4 results
Closes: https://github.com/ruby/ruby/pull/2135
|
|
|
|
| |
[Bug #15780]
|
| |
|
|
|
|
|
| |
is_pointer_to_heap() is used for conservative marking. To analyze
this function's behavior, introduce some debug_counters.
|
| |
|
| |
|
|
|
|
|
|
| |
This reverts commit 5776ae347540ac19c40d146a3566a806cd176bf1.
Mistaken `max` as `min`.
|
|
|
|
|
| |
Use improved description as suggested by Olivier Lacan (@olivierlacan),
see https://github.com/ruby/www.ruby-lang.org/pull/1888.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows cases such as:
```ruby
m ->(a = ->{@1}) {a}
m.call.call(1)
m2 ->(a: ->{@1}) {a}
m2.call.call(2)
```
Previously, this would cause a syntax error.
[Bug#15789]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows cases such as:
```ruby
m ->(a = ->{@1}) {a}
m.call.call(1)
m2 ->(a: ->{@1}) {a}
m2.call.call(2)
```
Previously, this would cause a syntax error.
[Bug#15789]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because `proc{|| @1}` is a syntax error, the following should
also be syntax errors:
```ruby
proc { |
| @1}
```
```ruby
proc { |; a| @1 }
```
This fixes both cases.
[Bug #15825]
|
|
|
|
| |
[Bug #15823]
|
| |
|
| |
|
|
|
|
|
| |
* parse.y (case_args): moved "duplicated when clause" warning from
compile phase, so that `ruby -wc` shows them.
|