August 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122915] [Ruby Bug#21531] /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env
by yahonda (Yasuo Honda) 07 Aug '25

07 Aug '25

Issue #21531 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21531: /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env https://bugs.ruby-lang.org/issues/21531 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: 3.5.0p-1 (2025-08-02 revision fca2e6f8f53920170654e696c2585fcd3f4ebe11) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Rails CI is consistently throwing assertion failures, but I can't replicate this behavior locally yet. https://buildkite.com/rails/rails-nightly/builds/2619#0198676f-b98c-4c4e-a6… ``` /usr/local/bin/ruby -w -I"lib:test" /usr/local/lib/ruby/gems/3.5.0+2/gems/rake-13.3.0/lib/rake/rake_test_loader.rb "test/activejob/destroy_association_async_job_test.rb" "test/activejob/destroy_association_async_test.rb" "test/activejob/job_checkpoints_test.rb" "test/activejob/job_runtime_test.rb" --profile /usr/local/lib/ruby/gems/3.5.0+2/gems/i18n-1.14.7/lib/i18n/exceptions.rb:3: warning: CGI library is removed from Ruby 3.5. Please use cgi/escape instead for CGI.escape and CGI.unescape features. If you need to use the full features of CGI library, Please install cgi gem. /usr/src/ruby/vm_insnhelper.c:131: Assertion Failed: callable_method_entry_p:IMEMO_TYPE_P((VALUE)cme, imemo_ment): imemo_type:env ruby 3.5.0dev (2025-08-01T16:00:05Z master fca2e6f8f5) +PRISM [x86_64-linux] ``` ### Environment - Using rubylang/ruby:master-debug Docker image provided via https://hub.docker.com/r/rubylang/ruby/ - Last successful build with Ruby 3.5.0p-1 (2025-08-01 revision b3598cf2a355497693bb66097edc156af3152e9b) [x86_64-linux] https://buildkite.com/rails/rails-nightly/builds/2614#01986249-5d8f-4315-ba… - I suspect this problem was introduced by one of the commits in this range: https://github.com/ruby/ruby/compare/b3598cf2a355497693bb66097edc156af3152e… -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114590] [Ruby master Bug#19857] Eval coverage is reset after each `eval`.
by ioquatix (Samuel Williams) 05 Aug '25

05 Aug '25

Issue #19857 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19857: Eval coverage is reset after each `eval`. https://bugs.ruby-lang.org/issues/19857 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- It seems like `eval` based coverage is reset every time eval is invoked. ```ruby #!/usr/bin/env ruby require 'coverage' def measure(flag) c = Class.new c.class_eval(<<~RUBY, "foo.rb", 1) def foo(flag) if flag puts "foo" else puts "bar" end end RUBY return c.new.foo(flag) end Coverage.start(lines: true, eval: true) # Depending on the order of these two operations, different computation is calculated, because the evaluation of the code is considered different, even if the content/path is the same. measure(false) measure(true) p Coverage.result ``` Further investigation is required. -- https://bugs.ruby-lang.org/

4 20

[ruby-core:121054] [Ruby master Bug#21139] Prism and parse.y parses `it = it` differently
by tompng (tomoya ishida) 05 Aug '25

05 Aug '25

Issue #21139 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21139: Prism and parse.y parses `it = it` differently https://bugs.ruby-lang.org/issues/21139 * Author: tompng (tomoya ishida) * Status: Assigned * Assignee: prism * ruby -v: ruby 3.5.0dev (2025-02-14T16:49:52Z master ee181d1bb7) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ~~~ # ruby --parser=parse.y -e "42.tap { it = it; p it }" nil # ruby --parser=prism -e "42.tap { it = it; p it }" 42 ~~~ -- https://bugs.ruby-lang.org/

12 18

[ruby-core:122910] [Ruby Bug#21530] Is IO#eof? supposed to always block and read?
by tenderlovemaking (Aaron Patterson) 05 Aug '25

05 Aug '25

Issue #21530 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21530: Is IO#eof? supposed to always block and read? https://bugs.ruby-lang.org/issues/21530 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm not sure whether or not this is expected behavior, but it seems like eof? blocks when called on $stdin. For example: ```ruby if (str = $stdin.gets) $stderr.puts "read #{str}" end if $stdin.eof? # this call waits for input $stderr.puts "stdin is eof" end ``` I think this is kind of odd behavior because if you input a string but _do not_ input a newline, then hit ^D twice, `$stdin` should be at EOF, but `eof?` will block and wait for input. If you hit ^D a third time, $stdin will be EOF, but if you input a different character it will not be EOF. Compare this C program: ```c #include <stdio.h> #include <stdlib.h> #define BUF_SIZE 4096 int main(int argc, char *argv[]) { char buf[BUF_SIZE]; if (fgets(buf, BUF_SIZE, stdin)) { fprintf(stderr, "read %s\n", buf); } if (feof(stdin)) { // Does not block fprintf(stderr, "stdin is EOF\n"); } } ``` If you hit ^D twice with this C program, `feof` will return true for `stdin`. I would have expected the Ruby program and the C program to behave similarly, but they don't. Is this expected? The documentation indeed says that `eof?` will read, but shouldn't the IO be at EOF after the second ^D? Thank you. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122817] [Ruby Bug#21517] Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial
by herwin (Herwin W) 03 Aug '25

03 Aug '25

Issue #21517 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21517: Behaviour of StringIO#readpartial with multibyte differs from IO#readpartial https://bugs.ruby-lang.org/issues/21517 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 3.4.5 (2025-07-16 revision 20cda200d3) +PRISM [x86_64-linux] (+ others) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The specs for `IO#readpartial` have the following test (https://github.com/ruby/spec/blob/ed254bae321221f5cd24280beb37e5bddaff6bb6/…) ```ruby before :each do @rd, @wr = IO.pipe @rd.binmode @wr.binmode end it "reads after ungetc with multibyte characters in the buffer" do @wr.write("∂φ/∂x = gaîté") c = @rd.getc @rd.ungetc(c) @rd.readpartial(3).should == "\xE2\x88\x82" @rd.readpartial(3).should == "\xCF\x86/" end ``` This behaviour is different in `StringIO#readpartial`. If I add this as a spec: ```ruby it "reads after ungetc with multibyte characters in the buffer" do @string = StringIO.new(+"∂φ/∂x = gaîté") c = @string.getc @string.ungetc(c) @string.readpartial(3).should == "\xE2\x88\x82" @string.readpartial(3).should == "\xCF\x86/" end ``` it fails with every supported Ruby version, and even with 3.5-dev of today, with the message `Expected "\xE2\x88\x82" == "∂"` The `getc` + `ungetc` can be removed, but this does not change the behaviour. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:122897] [Ruby Feature#21526] cryptocurrency & cybersecurity
by umershafique89＠gmail.com (Muhammad umar) 01 Aug '25

01 Aug '25

Issue #21526 has been reported by umershafique89(a)gmail.com (Muhammad umar). ---------------------------------------- Feature #21526: cryptocurrency & cybersecurity https://bugs.ruby-lang.org/issues/21526 * Author: umershafique89(a)gmail.com (Muhammad umar) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122892] [Ruby Bug#21525] Inconsistent execution order for methods with constant blocks
by joel＠drapper.me (Joel Drapper) 01 Aug '25

01 Aug '25

Issue #21525 has been reported by joel(a)drapper.me (Joel Drapper). ---------------------------------------- Bug #21525: Inconsistent execution order for methods with constant blocks https://bugs.ruby-lang.org/issues/21525 * Author: joel(a)drapper.me (Joel Drapper) * Status: Open * ruby -v: ruby 3.4.5 (2025-08-01 revision 07f7832cff) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- If you call a method and pass in a splat of an array with a block argument coerced from calling a method, Ruby maintains the expected execution order and the called method receives a copy of the array prior to modification. In this example, the output is `[1, 2, 3]` since the copy is made before the `bar` method can modify it. ```ruby ARRAY = [1, 2, 3] def bar ARRAY.pop -> {} end def example(*args, &) puts args end example(*ARRAY, &bar) ``` However, when passing a constant, the block coercion itself is able to modify the array. ```ruby ARRAY = [1, 2, 3] module Foo module Bar def self.to_proc ARRAY.pop -> {} end end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` Another way to trigger this is to define a `const_missing` method that modifies the array. ```ruby ARRAY = [1, 2, 3] module Foo def self.const_missing(name) ARRAY.pop -> {} end end def example(*args, &) puts args end example(*ARRAY, &Foo::Bar) ``` In both these cases, the output is `[1, 2]` instead of the expected `[1, 2, 3]`. -- https://bugs.ruby-lang.org/

2 2