| Age | Commit message (Collapse) | Author |
|---|
|
rake test is broken with system ruby
https://github.com/ruby/ruby/actions/runs/14768933827/job/41465573970?pr=13221
|
|
|
|
|
|
|
|
|
|
Or else it gets confused from all the different versions of LLVM in the
image.
|
|
|
|
|
|
v0.5.7 addresses CVE-2025-43857 (GHSA-j3g3-5qv5-52mj).
v0.5.8 fixes some bugs in `Net::IMAP::SequenceSet`.
|
|
Avoid generating an infinite loop in the case where:
1. Block `first` is adjacent to block `second`, and the branch from `first` to
`second` is a fallthrough, and
2. Block `second` immediately exits to the interpreter, and
3. Block `second` is invalidated and YJIT is OOM
While pondering how to fix this, I think I've stumbled on another related edge case:
1. Block `incoming_one` and `incoming_two` both branch to block `second`. Block
`incoming_one` has a fallthrough
2. Block `second` immediately exits to the interpreter (so it starts with its exit)
3. When Block `second` is invalidated, the incoming fallthrough branch from
`incoming_one` might be rewritten first, which overwrites the start of block
`second` with a jump to a new branch stub.
4. YJIT runs of out memory
5. The incoming branch from `incoming_two` is then rewritten, but because we're
OOM we can't generate a new stub, so we use `second`'s exit as the branch
target. However `second`'s exit was already overwritten with a jump to the
branch stub for `incoming_one`, so `incoming_two` will end up jumping to
`incoming_one`'s branch stub.
Backport [Bug #21257]
|
|
|
|
[Backport #21197]"
This reverts commit e630a0f7ae909dafe2e1dbc47baf90cd795b4a5f.
|
|
Fix coverage measurement for negative line numbers
Fixes [Bug #21220]
Co-Authored-By: Mike Bourgeous <mike@mikebourgeous.com>
Co-Authored-By: Jean Boussier <jean.boussier@gmail.com>
|
|
Fix `Integer.sqrt` to never exceed actual value
`Integer.sqrt` uses `sqrt(3)` from libm for small values.
This method must return a value less than or equal to the actual integer
square root, but libm's sqrt does not always guarantee that.
This change corrects that by decrementing the result if necessary.
Fixes [Bug #21217]
|
|
[ruby/prism] Freeze `Prism::VERSION`
Closes https://github.com/ruby/prism/pull/3422
https://github.com/ruby/prism/commit/b488a84253
|
|
[ruby/prism] Accept a newline after the defined? keyword
[Bug #21197]
https://github.com/ruby/prism/commit/22be955ce9
|
|
|
|
Fix segfault crash observable with TCPSocket.open(nil, nil)
|
|
|
|
|
|
|
|
https://rubyci.s3.amazonaws.com/s390x/ruby-master/log/20250403T060004Z.fail.html.gz
|
|
https://github.com/ruby/ruby/commit/3d8a66568e8106b367665d716e0d3c8c8208aa07
The original change is https://github.com/ruby/ruby/commit/d78ff6a767ca813ac5fa178dd7611f20a993c191
|
|
via vcpkg
|
|
[Bug #21211]
Socket errors raised from background threads are hard to track down because
their backtrace starts from the spawned thread.
To solve this we can raise a new error with the old one as `cause`.
|
|
https://github.com/rubygems/rubygems/commit/3e77caeddf
|
|
|
|
|
|
When we forward an FCALL (a method call with an implicit self), we
shouldn't forward the FCALL flag because it ignores method visibility
checks. This patch removes the FCALL flag from callers.
[Bug #21196]
|
|
[Bug #21195]
|
|
One error message that we parse is now slightly different.
https://github.com/rubygems/rubygems/commit/758528791d
|
|
[Backport #21094]
|
|
[Backport #21186]
|
|
Previously, vm_make_env_each() (used during proc
creation and for the debug inspector C API) picked up the
non-GC-allocated iseq that rb_vm_push_frame_fname() creates,
which led to a SEGV when the GC tried to mark the non GC object.
Put a real iseq imemo instead. Speed should be about the same since
the old code also did a imemo allocation and a malloc allocation.
Real iseq allows ironing out the special-casing of dummy frames in
rb_execution_context_mark() and rb_execution_context_update(). A check
is added to RubyVM::ISeq#eval, though, to stop attempts to run dummy
iseqs.
[Bug #21180]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
|
|
Previously, live range of `ast_value` ended on the call right before
rb_ast_dispose(), which led to premature collection and use-after-free.
We observed this crashing on -O3, -DVM_CHECK_MODE, with GCC 11.4.0 on
Ubuntu.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
|
|
The message from dlerror is not our concern.
|
|
|
|
|
|
[Bug #21179]
```
socket.rb:1046:in 'Socket::HostnameResolutionStore#get_addrinfo': can not access non-shareable objects in constant
Socket::HostnameResolutionStore::PRIORITY_ON_V6 by non-main ractor. (Ractor::IsolationError)
from socket.rb:724:in 'block in Socket.tcp_with_fast_fallback'
from socket.rb:720:in 'Socket.tcp_with_fast_fallback'
```
|
|
[Bug #21173]
When loading a file using the command line -r, it is processed before
RUBY_FREE_AT_EXIT is checked. So if the loaded file raises an error, it
will cause memory to not be freed with RUBY_FREE_AT_EXIT.
For example `ruby -rtest.rb -e ""` will report a large amount of memory
leaks if `test.rb` raises.
|
|
|
|
[Bug #21172]
This fixes a rare CI failure.
The timeline of the race condition is:
- A `"foo" oid=1` string is interned.
- `"foo" oid=1` is no longer referenced and will be swept in the future.
- Another `"foo" oid=2` string is interned.
- `register_fstring` finds `"foo" oid=1`, but since it is about to be swept,
removes it from `fstring_table` and insert `"foo" oid=2` instead.
- `"foo" oid=1` is swept, since it has the `RSTRING_FSTR` flag,
a `st_delete` is issued in `fstring_table` which removes `"foo" oid=2`.
I don't know how to reproduce this bug consistently in a single test
case.
|
|
[Bug #21170]
st_table reserves -1 as a special hash value to indicate that an entry
has been deleted. So that that's a valid value to be returned from the
hash function, do_hash replaces -1 with 0 so that it is not mistaken for
the sentinel.
Previously, when upgrading an AR table to an ST table,
rb_st_add_direct_with_hash was used which did not perform the same
conversion, this could lead to a hash in a broken state where one if its
entries which was supposed to exist being marked as a tombstone.
The hash could then become further corrupted when the ST table required
resizing as the falsely tombstoned entry would be skipped but it would
be counted in num entries, leading to an uninitialized entry at index
15.
In most cases this will be really rare, unless using a very poorly
implemented custom hash function.
This also adds two debug assertions, one that st_add_direct_with_hash
does not receive the reserved hash value, and a second in
rebuild_table_with, which ensures that after we rebuild/compact a table
it contains the expected number of elements.
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
|
|
|
|
If the TZ environment variable is not set, the time zone names
retrieved from the system are localized for UI display and may vary
across editions and language packs for the same time zone.
Use the time zone IDs that are invariant across environments instead.
|
|
[Bug #21161]
The `tolower` function provided by the libc is locale dependent
and can behave in ways you wouldn't expect for some value
of `LC_CTYPE`.
https://github.com/ruby/prism/commit/e3488256b4
Co-Authored-By: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
|
|
|
|
|
Otherwise, changes to the buffer by the destination write method
could result in data changing for supposedly independent strings.
Fixes [Bug #21131]
|
|
When the end points of an inclusive range equal, `Range#step` should
yields the element once.
|
