| Age | Commit message (Collapse) | Author |
|---|
|
on null device
(https://github.com/ruby/stringio/pull/137)
Fixes segmentation fault when calling `seek` with `SEEK_END` on null
device StringIO created by
`StringIO.new(nil)`.
```bash
ruby -e "require 'stringio'; StringIO.new(nil).seek(0, IO::SEEK_END)"
```
I tested with below versions.
```bash
[koh@Kohs-MacBook-Pro] ~
% ruby -v;gem info stringio;sw_vers
ruby 3.4.5 (2025-07-16 revision https://github.com/ruby/stringio/commit/20cda200d3) +PRISM [arm64-darwin24]
*** LOCAL GEMS ***
stringio (3.1.2)
Authors: Nobu Nakada, Charles Oliver Nutter
Homepage: https://github.com/ruby/stringio
Licenses: Ruby, BSD-2-Clause
Installed at (default): /Users/koh/.local/share/mise/installs/ruby/3.4.5/lib/ruby/gems/3.4.0
Pseudo IO on String
ProductName: macOS
ProductVersion: 15.5
BuildVersion: 24F74
[koh@Kohs-MacBook-Pro] ~
%
```
https://github.com/ruby/stringio/commit/9399747bf9
|
|
Previously, if GC was in progress when we're initially building the
id2ref table, it could see the empty table and then crash when trying to
remove ids from it. This commit fixes the bug by only publishing the
table after GC is done.
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
|
|
In rb_ractor_sched_wait() (ex: Ractor.receive), we acquire
RACTOR_LOCK(cr) and then thread_sched_lock(cur_th). However, on wakeup
if we're a dnt, in thread_sched_wait_running_turn() we acquire
thread_sched_lock(cur_th) after condvar wakeup and then RACTOR_LOCK(cr).
This lock inversion can cause a deadlock with rb_ractor_wakeup_all()
(ex: port.send(obj)), where we acquire RACTOR_LOCK(other_r) and then
thread_sched_lock(other_th).
So, the error happens:
nt 1: Ractor.receive
rb_ractor_sched_wait() after condvar wakeup in thread_sched_wait_running_turn():
- thread_sched_lock(cur_th) (condvar) # acquires lock
- rb_ractor_lock_self(cr) # deadlock here: tries to acquire, HANGS
nt 2: port.send
ractor_wakeup_all()
- RACTOR_LOCK(port_r) # acquires lock
- thread_sched_lock # tries to acquire, HANGS
To fix it, we now unlock the thread_sched_lock before acquiring the
ractor_lock in rb_ractor_sched_wait().
Script that reproduces issue:
```ruby
require "async"
class RactorWrapper
def initialize
@ractor = Ractor.new do
Ractor.recv # Ractor doesn't start until explicitly told to
# Do some calculations
fib = ->(x) { x < 2 ? 1 : fib.call(x - 1) + fib.call(x - 2) }
fib.call(20)
end
end
def take_async
@ractor.send(nil)
Thread.new { @ractor.value }.value
end
end
Async do |task|
10_000.times do |i|
task.async do
RactorWrapper.new.take_async
puts i
end
end
end
exit 0
```
Fixes [Bug #21398]
Co-authored-by: John Hawthorn <john.hawthorn@shopify.com>
|
|
These `...` ISEQs have a special calling convention in the interpreter
and our stubs and JIT calling convention don't deal well. Reject for now.
Debugged with help from `@tekknolagi` and `tool/zjit_bisect.rb`.
Merely avoiding direct sends is enough to pass the attached test, but also
avoid compiling ISEQs with `...` parameter to limit exposure for now.
`SendWithoutBlock`, which does dynamic dispatch using interpreter code,
seems to handle calling into forwardable ISEQs correctly, so they are
fine -- we can't predict where these dynamic sends land anyways.
|
|
|
|
This reverts commit 8e9ea4c202fb104d7c17ad1f3cc59d697120501a.
The environment variable is converted internally.
|
|
This reverts commit 79d8a3159f60d32396c8281fe438e86ab97e3daa.
The second argument of `find_executable0` in mkmf is `path`, not
arguments to the program like as `EnvUtil.find_executable`.
|
|
https://github.com/ruby/optparse/commit/2f9c7500a3
|
|
|
|
Replace `rb_yarv_class_of` call with:
- a constant check for special constants (nil, fixnums, symbols, etc)
- a check for false
- direct memory read at offset 8 for regular heap objects for the class check
|
|
We can rewrite SendWithoutBlock to GetIvar.
|
|
* ZJIT: Implement SingleRactorMode invalidation
* ZJIT: Add macro for compiling jumps
* ZJIT: Fix typo in comment
* YJIT: Fix typo in comment
* ZJIT: Avoid using unexported types in zjit.h
`enum ruby_vminsn_type` is declared in `insns.inc` and is not exported.
Using it in `zjit.h` would cause build errors when the file including it
doesn't include `insns.inc`.
|
|
|
|
Co-authored-by: Alan Wu <alansi.xingwu@shopify.com>
|
|
Add `keyword_module` amd `keyword_end` locations to struct `RNode_MODULE`.
memo:
```
>ruby --dump=parsetree -e 'module A end'
@ ProgramNode (location: (1,0)-(1,12))
+-- locals: []
+-- statements:
@ StatementsNode (location: (1,0)-(1,12))
+-- body: (length: 1)
+-- @ ModuleNode (location: (1,0)-(1,12))
+-- locals: []
+-- module_keyword_loc: (1,0)-(1,6) = "module"
+-- constant_path:
| @ ConstantReadNode (location: (1,7)-(1,8))
| +-- name: :A
+-- body: nil
+-- end_keyword_loc: (1,9)-(1,12) = "end"
+-- name: :A
```
|
|
It's not rare for structs to have additional ivars, hence are one
of the most common, if not the most common type in the `gen_fields_tbl`.
This can cause Ractor contention, but even in single ractor mode
means having to do a hash lookup to access the ivars, and increase
GC work.
Instead, unless the struct is perfectly right sized, we can store
a reference to the associated IMEMO/fields object right after the
last struct member.
```
compare-ruby: ruby 3.5.0dev (2025-08-06T12:50:36Z struct-ivar-fields-2 9a30d141a1) +PRISM [arm64-darwin24]
built-ruby: ruby 3.5.0dev (2025-08-06T12:57:59Z struct-ivar-fields-2 2ff3ec237f) +PRISM [arm64-darwin24]
warming up.....
| |compare-ruby|built-ruby|
|:---------------------|-----------:|---------:|
|member_reader | 590.317k| 579.246k|
| | 1.02x| -|
|member_writer | 543.963k| 527.104k|
| | 1.03x| -|
|member_reader_method | 213.540k| 213.004k|
| | 1.00x| -|
|member_writer_method | 192.657k| 191.491k|
| | 1.01x| -|
|ivar_reader | 403.993k| 569.915k|
| | -| 1.41x|
```
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
|
|
invoked
https://github.com/rubygems/rubygems/commit/261315e399
|
|
https://github.com/rubygems/rubygems/commit/42c5947dbe
|
|
https://github.com/rubygems/rubygems/commit/e09a6ec815
|
|
to test
https://github.com/rubygems/rubygems/commit/5b4eece722
|
|
at RG 4.1
https://github.com/rubygems/rubygems/commit/e99cdab171
|
|
https://github.com/ruby/prism/commit/a6b448b10f
|
|
https://github.com/ruby/prism/commit/659d769621
|
|
Currently Prism returns `42` for code like this:
```ruby
42.tap { it = it; p it } # => 42
```
But parse.y returns `nil`:
```ruby
42.tap { it = it; p it } # => nil
```
In parse.y, it on the right-hand side is parsed as a local variable.
In Prism, it was parsed as the implicit block parameter it, which caused this inconsistent behavior.
This change makes the right-hand side it to be parsed as a local variable, aligning with parse.y's behavior.
Bug ticket: https://bugs.ruby-lang.org/issues/21139
https://github.com/ruby/prism/commit/cf3bbf9d2c
|
|
https://github.com/ruby/prism/commit/915f6b3ae9
|
|
https://github.com/ruby/prism/commit/27d284bbb8
|
|
https://github.com/ruby/prism/commit/f5ded5104d
|
|
command calls
https://github.com/ruby/prism/commit/d9151b8a82
|
|
A command-call-like `not true` must be rejected after `&&` and `||`.
https://bugs.ruby-lang.org/issues/21337
https://github.com/ruby/prism/commit/0513cf22ad
|
|
|
|
|
|
|
|
Failed at:
https://github.com/ruby/ruby/actions/runs/16737407508/job/47378992863
Partially reverting https://github.com/ruby/ruby/pull/14097
|
|
This can still hang:
https://github.com/ruby/ruby/actions/runs/16735509694/job/47373381258
partially reverting https://github.com/ruby/ruby/pull/14097
|
|
|
|
Paths in environment variables should already be expanded.
The base name of the program is also not subject to expansion.
https://github.com/ruby/optparse/commit/181752391c
|
|
https://github.com/ruby/optparse/commit/e0fdabf946
|
|
|
|
Previously, ARM64 panicked due to compiled_side_exits() when the memory
displacement got large enough to exceed the 9 bits limit. Usually, we split
these kind of memory operands, but compiled_side_exits() runs after
split.
Using scratch registers, implement `Insn::Store` on ARM such that it can
handle large displacements without split(). Do this for x86 as well, and
remove arch specific code from compiled_side_exits(). We can now run
`TestKeywordArguments`.
Since `Insn::Store` doesn't need splitting now, users enjoy lower
register pressure.
Downside is, using `Assembler::SCRATCH_REG` as a base register is now
sometimes an error, depending on whether `Insn::Store` also needs to
use the register. It seems a fair trade off since `SCRATCH_REG` is
not often used, and we don't put it as a base register anywhere at the
moment.
|
|
https://github.com/ruby/prism/commit/7362b114a3
|
|
https://github.com/ruby/prism/commit/c2e372a8d8
|
|
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
|
|
Add a simple test case that creates an enveloped-data structure without
using the shorthand method, and fix two issues preventing this from
working correctly.
First, OpenSSL::PKey::PKCS7#add_recipient currently inserts an
incomplete PKCS7_RECIP_INFO object into the PKCS7 object. When
duplicating an unfinalized PKCS7_RECIP_INFO, the internal X509 reference
must also be copied, as it is later used by #add_data to fill the rest.
A similar issue with #add_signer was fixed in commit https://github.com/ruby/openssl/commit/20ca7a27a86e
(pkcs7: keep private key when duplicating PKCS7_SIGNER_INFO,
2021-03-24).
Second, #add_data calls PKCS7_dataFinal(), which for enveloped-data
appears to require the BIO to be flushed explicitly with BIO_flush().
Without this, the last block of the encrypted data would be missing.
https://github.com/ruby/openssl/commit/9595ecf643
|
|
Only call PKCS7_get_detached() if the PKCS7 object is a signed-data.
This is only useful for the content type, and leaves an error entry if
called on a PKCS7 object with a different content type.
https://github.com/ruby/openssl/commit/8997f6d5e6
|
|
If `get_next_shape_internal` fail to return a shape, we must
transitiont to a complex shape. `shape_transition_object_id`
mistakenly didn't.
Co-Authored-By: Peter Zhu <peter@peterzhu.ca>
|
|
On the ruby side, this fixes a crash for methods with 39 or more
parameters. We used to miscomp those entry points due to Insn::Lea
picking ADDS which cannot reference SP:
# set method params: 40
mov x0, #0xfee8
movk x0, #0xffff, lsl #16
movk x0, #0xffff, lsl #32
movk x0, #0xffff, lsl #48
adds x0, xzr, x0
Have Lea work for all i32 displacements and avoid involving the split
pass. Previously, direct use of Insn::Lea directly from the user (as
opposed to generated by the split pass for some memory operations)
wasn't split, so being able to handle the whole range in arm64_emit()
was implicitly required. Also, not going through split reduces register
pressure.
|
|
This includes:
- Update test keys to the generic rsa-{1,2,3}.pem.
- Add omissions for enveloped-data tests so that the rest can be
tested in the FIPS mode.
- Add tests for PKCS7#error_string and #data.
- Check more error paths.
- Various style fixes.
https://github.com/ruby/openssl/commit/58f0022de3
|
|
Commit https://github.com/ruby/openssl/commit/ef277083ba76 overlooked a caller of ossl_x509_new() with NULL
argument. OpenSSL::X509::StoreContext#current_cert may not have a
certificate to return if StoreContext#verify has not been called.
https://github.com/ruby/openssl/commit/4149b43890
|
|
|
|
Previously, endless method definitions in assignment contexts like
`x = def f = p 1` would fail to parse because command calls (method
calls without parentheses) were only accepted when the surrounding
binding power was less than `PM_BINDING_POWER_COMPOSITION`.
This fix specifically checks for assignment context and allows command
calls in those cases while maintaining the existing behavior for other
contexts. This ensures that:
- `x = def f = p 1` parses correctly (previously failed)
- `private def f = puts "Hello"` still produces the expected error
https://github.com/ruby/prism/commit/722af59ba3
|
