July 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:114031] [Ruby master Bug#19746] `String#index` with regexp and too large offset doesn't clear `$~`
by nobu (Nobuyoshi Nakada) 22 Jul '23

22 Jul '23

Issue #19746 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19746: `String#index` with regexp and too large offset doesn't clear `$~` https://bugs.ruby-lang.org/issues/19746 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```ruby /./ =~ "a" p "x".index(/0/, 4) #=> nil p $~ #=> #<MatchData "a"> ``` while `rindex` does. ```ruby /./ =~ "a" p "x".rindex(/0/, 4) #=> nil p $~ #=> nil ``` It seems since 1.9. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112926] [Ruby master Misc#19535] Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID`
by byroot (Jean Boussier) 22 Jul '23

22 Jul '23

Issue #19535 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #19535: Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID` https://bugs.ruby-lang.org/issues/19535 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context I've been helping the Mastodon folks in investigating a weird Marshal deserialization bug they randomly experience since they upgraded to Ruby 3.2: https://github.com/mastodon/mastodon/issues/23644 Ultimately the bug comes from a circular dependency issues in the object graph that is serialized when one call `Marshal.dump` on an `ActiveRecord::Base` object. A simplified reproduction to better explain the problem is: ```ruby class Status def normal_order @attributes = { id: 42 } @relations = { self => 1 } self end def inverse_order @relations = nil @attributes = { id: 42 } @relations = { self => 1 } self end def hash @attributes.fetch(:id) end end s = Marshal.load(Marshal.dump(Status.new.normal_order)) s = Marshal.load(Marshal.dump(Status.new.inverse_order)) ``` In short, that `Status` object is both the top level object, and is referenced as a key in a hash, in that same payload. It also defined a custom `#hash` method, that requires some other attribute to be set. It all "works" as long as `@attributes` is dumped before `@relations`. ### Problem The above micro-reproduction uses two different shapes to demonstrate the ordering issues, but in both case the ordering is predictable. However if you generate too many shapes from a single class, it will be marked as `TOO_COMPLEX` and future instance will have their instance variables backed by an `id_table`, which is unordered, and will cause a similar issue. I definitely consider this a bug on the Rails side, and I will do what I can so that Rails doesn't depend on that implicit ordering. However it's unlikely we'll be able to fix older version, and other users may run into this issue when upgrading to Ruby 3.2, so I think it may be worth to try to preserve some sort of predicable ordering, at least for a few more versions. Additionally, debugging it was made particularly difficult, because it would work fine initially, and then break after enough shapes had been generated. Generally speaking I think such semi-predictable behavior is much worse than a fully random behavior (similar to how Go randomize keys order in their maps). ### Historical behavior On Ruby 3.1 and older, the instance variables ordering was defined by the order in which each ivar appeared for the very first time: ```ruby class Foo def set @a = 1 @b = 2 @c = 3 self end def inverse_order @c = 3 @b = 2 @a = 1 self end end p Foo.new.set.instance_variables # => [:@a, :@b, :@c] p Foo.new.inverse_order.instance_variables # => [:@a, :@b, :@c] ``` This means that the order could be different from once execution of the program to another, but would remain stable inside a single process. On 3.2, it's now defined by the order in which each ivar appeared in that specific object instance: ```ruby [:@a, :@b, :@c] [:@c, :@b, :@a] ``` Except, if the object is backed by an `id_table`, in which case it's fully unpredictable. ### Possible changes I discussed this with @tenderlovemaking, and he suggested we could change the `id_table` for an `st_table` so that the ordering could be predictable again, and would behave like objects with a non-complex shape. Another possibility would be to preserve the observable behavior of 3.1 and older. Or of course we could clearly specify that the ordering is random, but if so I think it would be wise to make it always random so that this class of bugs has a much higher chance to be caught early in testing rather than in production. cc @Eregon as I presume this has implications on TruffleRuby as well. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:113482] [Ruby master Bug#19640] `IO#puts` can generate zero length iov which can cause rb_bug crash.
by ioquatix (Samuel Williams) 22 Jul '23

22 Jul '23

Issue #19640 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19640: `IO#puts` can generate zero length iov which can cause rb_bug crash. https://bugs.ruby-lang.org/issues/19640 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED ---------------------------------------- In the fiber scheduler, `IO#puts ""` or `IO#puts nil` can generate a zero length `iov` which causes `io_binwritev_internal` to fail since the result is zero. We need to fix `IO#puts` so that it does not generate zero length writes, but also we fix `io_binwritev_internal` to handle this case more robustly. Fix: https://github.com/ruby/ruby/pull/7806/files -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113745] [Ruby master Bug#19709] `Thread.join(timeout)` hangs in fiber scheduler.
by ioquatix (Samuel Williams) 22 Jul '23

22 Jul '23

Issue #19709 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19709: `Thread.join(timeout)` hangs in fiber scheduler. https://bugs.ruby-lang.org/issues/19709 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Unfortunately the following script can hang: ```ruby require_relative 'test/fiber/scheduler' scheduler = Scheduler.new Fiber.set_scheduler scheduler Fiber.schedule do thread = Thread.new{sleep} thread.join(0.1) end ``` The termination condition in the `thread_join` is not expressed correctly. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:113977] [Ruby master Bug#19743] Ruby's parser seems to ignoring DOT at the end of file just after digits
by tompng (tomoya ishida) 22 Jul '23

22 Jul '23

Issue #19743 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #19743: Ruby's parser seems to ignoring DOT at the end of file just after digits https://bugs.ruby-lang.org/issues/19743 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-06-19T09:28:10Z master 2a80bac9f0) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I expect all to be syntax error ~~~ruby eval "puts 1." #=> 1 eval "puts 1. " #=> syntax error eval "puts 1.\n" #=> syntax error ~~~ For ripper, period token is missing ~~~ruby Ripper.tokenize("1.") #=> ["1"] Ripper.tokenize("1. ") #=> ["1", ".", " "] ~~~ -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113380] [Ruby master Bug#19623] Ruby 3.2 MJIT crashes on railsbench
by k0kubun (Takashi Kokubun) 22 Jul '23

22 Jul '23

Issue #19623 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19623: Ruby 3.2 MJIT crashes on railsbench https://bugs.ruby-lang.org/issues/19623 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- Ruby 3.2 MJIT crashes on railsbench when you use `--mjit-max-cache=10000`. ``` [2023-04-29T22:49:00.915217 #412381] FATAL -- : [bc56d52f-5930-4307-8af7-3f58a44eb089] [bc56d52f-5930-4307-8af7-3f58a44eb089] NoMethodError (undefined method `[]' for #<Class:Object>): [bc56d52f-5930-4307-8af7-3f58a44eb089] [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/inflections.rb:65:in `instance' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/inflections.rb:252:in `inflections' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `block in camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `sub' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/core_ext/string/inflections.rb:94:in `camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/request.rb:87:in `controller_class_for' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:100:in `binary_params_for?' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:91:in `set_binary_encoding' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:69:in `path_parameters=' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:47:in `block in serve' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:32:in `each' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:32:in `serve' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/routing/route_set.rb:834:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/tempfile_reaper.rb:15:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/etag.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/conditional_get.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/head.rb:12:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/content_security_policy.rb:18:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/session/abstract/id.rb:266:in `context' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/session/abstract/id.rb:260:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/cookies.rb:654:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/callbacks.rb:101:in `run_callbacks' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/callbacks.rb:26:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/debug_exceptions.rb:32:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:37:in `call_app' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:26:in `block in call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:80:in `block in tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:28:in `tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:80:in `tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:26:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/remote_ip.rb:81:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/request_id.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/method_override.rb:24:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/runtime.rb:22:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/executor.rb:14:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/sendfile.rb:110:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/host_authorization.rb:76:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/engine.rb:527:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:28:in `block (2 levels) in <main>' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:25:in `each' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:25:in `block in <main>' [bc56d52f-5930-4307-8af7-3f58a44eb089] /home/k0kubun/src/github.com/Shopify/yjit-bench/harness/harness.rb:29:in `block in run_benchmark' [bc56d52f-5930-4307-8af7-3f58a44eb089] /opt/rubies/mjit/lib/ruby/3.2.0+3/benchmark.rb:311:in `realtime' [bc56d52f-5930-4307-8af7-3f58a44eb089] /home/k0kubun/src/github.com/Shopify/yjit-bench/harness/harness.rb:29:in `run_benchmark' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:24:in `<main>' ``` This PR https://github.com/ruby/ruby/pull/7774 fixes the problem. This ticket is to request a backport for Ruby 3.2. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113382] [Ruby master Bug#19625] Ruby 3.2 MJIT never triggers JIT compaction
by k0kubun (Takashi Kokubun) 22 Jul '23

22 Jul '23

Issue #19625 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19625: Ruby 3.2 MJIT never triggers JIT compaction https://bugs.ruby-lang.org/issues/19625 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- [This patch](https://github.com/ruby/ruby/pull/6900) accidentally removed a condition to trigger JIT compaction from Ruby 3.2. This PR https://github.com/ruby/ruby/pull/7777 makes it work again. This ticket is to request a backport for Ruby 3.2. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:114255] [Ruby master Bug#19025] Ripper cannot parse syntax ok code that has numbered parameters
by nagachika (Tomoyuki Chikanaga) 22 Jul '23

22 Jul '23

Issue #19025 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ruby_3_2 465eb7418d7ed91f5f0c75da77765c7f5ef8354f merged revision(s) 91c004885fc75a93cadf0094fa86ec3bd0ec25f5. ---------------------------------------- Bug #19025: Ripper cannot parse syntax ok code that has numbered parameters https://bugs.ruby-lang.org/issues/19025#change-103944 * Author: tompng (tomoya ishida) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-09-22T02:42:57Z :detached: 830b2e217b) [x86_64-linux] * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: DONE ---------------------------------------- Ruby says `p { a = 0; [_1, _1 **2] }` is syntax ok, Ripper says syntax error ~~~ruby code = 'p { a = 0; [_1, _1 **2] }' eval(code) #=> nil (Syntax OK) Ripper.sexp(code) #=> nil (Syntax Error) ~~~ Other similar codes. maybe not a bug ~~~ruby p { a = 0; [a **2] } # Syntax OK p { a = 0; [_1 **2] } # Syntax Error p { a = 0; [a, _1 **2] } # Syntax Error p { a = 0; [_1, _1 **2] } # Syntax OK, Ripper.sexp says Syntax Error ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112906] [Ruby master Bug#19531] ObjectSpace::WeakMap: replaced values still clear the key they were assigned to
by byroot (Jean Boussier) 22 Jul '23

22 Jul '23

Issue #19531 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19531: ObjectSpace::WeakMap: replaced values still clear the key they were assigned to https://bugs.ruby-lang.org/issues/19531 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ### Reproduction script ```ruby wmap = ObjectSpace::WeakMap.new a = "A" b = "B" wmap[1] = a wmap[1] = b # the table entry with 1 is still in the list of entries to clear when `a` is GCed a = nil GC.start p wmap[1] # Should be `"B"`, but is `nil` ``` ### Explanation What happens is that when we set `wmap[1] = "A"`, WeakMap internally keeps a list of keys to clear when `"A"` is GCed, e.g. pseudo code: ```ruby class WeakMap def []=(key, value) @hash[key] = value @reverse[value] << key end end ``` But it doesn't clear previously kept mapping when a key is overwritten. I'll work on a fix. ### References https://github.com/protocolbuffers/protobuf/pull/12216 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:114252] [Ruby master Feature#19780] Remove tailcall_optimization support
by k0kubun (Takashi Kokubun) 22 Jul '23

22 Jul '23

Issue #19780 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Feature #19780: Remove tailcall_optimization support https://bugs.ruby-lang.org/issues/19780 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- ## Proposal Remove `tailcall_optimization` flag from `RubyVM::InstructionSequence` ## Motivation The consensus at [Feature #6602] seems to be that we're not going to enable tailcall optimization by default until we introduce syntax for it. Until this syntax is introduced, this feature is useless. Can we remove this flag until we do support that future syntax? ## Background This script doesn't work with `--yjit-call-threshold=1` on any YJIT-enabled build. ```rb src = <<-EOS def apply_one_and_two(&block) [1, p(1)] end def add_one_and_two apply_one_and_two(&:+) end EOS RubyVM::InstructionSequence.new( "proc {|_|_.class_eval {#{src}}}", __FILE__, __FILE__, 1, tailcall_optimization: true, trace_instruction: false, ).eval[self.singleton_class] def entry add_one_and_two end entry ``` I already wasted a lot of time just for noticing it's already broken. I don't want to waste time for users that do not exist yet. -- https://bugs.ruby-lang.org/

1 0