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

[ruby-core:112523] [Ruby master Bug#19454] Instruction `send` has nil blockiseq parameter and ARGS_SIMPLE flag
by dmitry.pogrebnoy (Dmitry Pogrebnoy) 22 Feb '23

22 Feb '23

Issue #19454 has been reported by dmitry.pogrebnoy (Dmitry Pogrebnoy). ---------------------------------------- Bug #19454: Instruction `send` has nil blockiseq parameter and ARGS_SIMPLE flag https://bugs.ruby-lang.org/issues/19454 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ### Setup * OS: MacOS Monterey 12.4 * VM: rbenv * Gems: test-unit 3.5.3 * Ruby: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] ### Problem Description In some cases the instruction `send` has `nil` block argument and `ARGS_SIMPLE` flag. But `send` is supposed to have a valid `blockiseq` parameter. For the case with a missing block there is an instruction `opt_send_without_block`. This breaks some of the logic of the dependent program . ### How to reproduce 1. Open attached project and run test in test_project\test\my_example_test.rb You should get this output: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,22)> (catch: FALSE) 0000 opt_getinlinecache 9, <is:0> ( 1)[Li] 0003 putobject true 0005 getconstant :MyModule 0007 opt_setinlinecache <is:0> 0009 send <calldata!mid:some_method, argc:0, ARGS_SIMPLE>, nil 0012 leave ``` Here you can see the `send` insn with nil blockiseq and ARGS_SIMPLE flag. 2. But if you run the same code as a script (lib\my_example_script.rb) you should get this output: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,22)> (catch: FALSE) 0000 opt_getinlinecache 9, <is:0> ( 1)[Li] 0003 putobject true 0005 getconstant :MyModule 0007 opt_setinlinecache <is:0> 0009 opt_send_without_block <calldata!mid:some_method, argc:0, ARGS_SIMPLE> 0011 leave ``` Here you can see the `opt_send_without_block` insn instead of `send`. It would be good to get rid of `send` insn with nil blockiseq and use `opt_send_without_block` instruction in such cases. ---Files-------------------------------- test_project.zip (38.3 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112528] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by Eregon (Benoit Daloze) 21 Feb '23

21 Feb '23

Issue #18285 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-38: > ``` > new: undefined method `foo' for main > ``` I think that's quite confusing though without the `main:Object`, because `main` has many other meanings (main script = $0, main function, etc). So I'd suggest either: ``` undefined method `foo' for main:Object undefined method `foo' for main object ``` ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101976 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112527] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by ivoanjo (Ivo Anjo) 21 Feb '23

21 Feb '23

Issue #18285 has been updated by ivoanjo (Ivo Anjo). Thank you! :) ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101975 * Author: ivoanjo (Ivo Anjo) * Status: Closed * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112313] [Ruby master Feature#19428] Adding a "piped heredoc" feature
by shreeve (Steve Shreeve) 20 Feb '23

20 Feb '23

Issue #19428 has been reported by shreeve (Steve Shreeve). ---------------------------------------- Feature #19428: Adding a "piped heredoc" feature https://bugs.ruby-lang.org/issues/19428 * Author: shreeve (Steve Shreeve) * Status: Open * Priority: Normal ---------------------------------------- Hello, I hope this is the correct place to post a small feature request. HEREDOC's are awesome! There are several used within Ruby: ```ruby <<END Have to left justify this END <<-INDENTED Still left justified, but indented ending INDENTED <<~SQUIGGLY I can indent content it will be smartly "dedented/undented". Looks nicer. SQUIGGLY ``` I love using the SQUIGGLY heredoc, which will strip off the minimum whitespace from the front of each line in the heredoc. I often do something like this: ```ruby options = { name: "My Nice Options", description: <<~END This is a cool set of options. You Can put what you like here. END } ``` If you need to continue with the above, you can add a comma after like this: ```ruby options = { name: "My Nice Options", description: <<~END, This is a cool set of options. You Can put what you like here. END details: <<~END, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. END } ``` You can even get a little squirrely and use an empty string for a heredoc terminator: ```ruby options = { name: "My Nice Options", description: <<~"", This is a cool set of options. You Can put what you like here. details: <<~"", Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` There's one variation that I think would be nice to add, I call it a "piped heredoc". It would essentially work like the squiggly heredoc, but the "terminator" would be the next line that is not indented, and thus not "part of the heredoc". Here's an example: ```ruby options = { name: "My Nice Options", description: <<|, This is a cool set of options. You Can put what you like here. details: <<|, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` Since the leading whitespace is used to tell when the heredoc ends, there is no need for an explicit terminator. You could add one if you'd like to indicate the flavor of the content, for syntax highlighters, but it's value is ignored: ```ruby options = { name: "My Nice Options", description: <<|RUBY, users.each do |user| user.pay_daily_bonus! end details: <<|, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` In the above, the "RUBY" is not really needed, but it is a hint to format that block as Ruby code. This tweak to Ruby's heredocs seems like it could make Ruby syntax easy and fun to read. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:112493] RUBY_PLATFORM shows `x32' on `x86' userspace
by Eric Wong 19 Feb '23

19 Feb '23

Not sure it's a bug or not, but it probably is... My RUBY_PLATFORM is `x86_64-linux-x32' nowadays (it was only `x86_64-linux' previously, but that was also inaccurate). I'm running x86_64 Linux kernel, but a Debian i386 userspace (really i486). x32 is newer, better 32-bit userspace mode for 64-bit kernels. However, x32 is basically abandoned due to lack of adoption, so I keep using i[3-6]86. $ file ./ruby ./ruby: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=fc8fe2291ef2987e717248b777ef4a130dca9251, for GNU/Linux 3.2.0, with debug_info, not stripped $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/10/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) *shrug*

1 0

[ruby-core:112492] [Ruby master Feature#19024] Proposal: Import Modules
by shioyama (Chris Salzberg) 19 Feb '23

19 Feb '23

Issue #19024 has been updated by shioyama (Chris Salzberg). I wanted to update this because I've changed my thinking since the original proposal. TL;DR 1. I agree that we should not change `require`, `require_relative`, `load` or `autoload` (at least, not in ways that would break existing usage). Thanks @jeremyevans0 and others for convincing me of this. 2. Any new way to import code should be _opt-in_. Again, many voiced this opinion here and it makes sense to me now. I decided to take these two as constraints and see what else was possible in Ruby 3.2, and came up with (a new version of) [Im](https://github.com/shioyama/im). Im is an "isolated module autoloader", a fork of Zeitwerk which autoloads constants under an anonymous namespace. The interface for Im is nearly identical to Zeitwerk except that rather than loading to top-level, constants are loaded under loaders themselves, where `Im::Loader` subclasses `Module` and can therefore define its own namespace. So for gem code, it looks like this: ```ruby # lib/my_gem.rb (main file) require "im" loader = Im::Loader.for_gem loader.setup # ready! module loader::MyGem # ... end loader.eager_load # optionally ``` Notice here that `loader` encapsulates the entire loaded namespace. Further details in the [readme](https://github.com/shioyama/im/blob/main/README.md). I've also built a [sample Rails app](https://bugs.ruby-lang.org/issues/17881) which uses Im to load all its code under a single application namespace. Internally Im uses `load` with the second module argument (discussed here) and also `Module#const_added` ([ref](https://bugs.ruby-lang.org/issues/17881)) also added in Ruby 3.2. The advantages to this approach: - autoloading does not require "returning" anything, unlike `require`, where any change would face the problem of where to "receive" the thing you've loaded if not at toplevel. For the most part you can just write your code exactly as you would any other Zeitwerk-autoloaded code, without any `import` calls in each file, and for a gem you just `import` the gem once and get the whole tree of autoloaded code. - the Zeitwerk convention for file naming/loading (inherited from Rails) is now widely adopted, and so the changes to make a gem "Im-compatible" should generally be quite small. (The exception here is Rails, which depends heavily on `Module#name` to map association names, etc.) - Although the approach does not guarantee isolation (e.g. you can always "break out" by referencing toplevel with `::Foo`), it _can_ guarantee a kind of "opt-in" isolation, whereby _within your autoloaded code you own the toplevel (because your "toplevel" is the top of an anonymous-rooted module namespace). Similarly, a gem can entirely remove itself from the global namespace, instead allowing the gem consumer to determine the top constant name under which to load code. So two gems that follow the convention are isolated from each other provided they don't create/modify anything at the "absolute toplevel". @rubyFeedback > This can lead to problems sometimes. I agree it is not a huge problem per se I disagree here, I think this is actually a huge issue, and I think it's only because we as Rubyists are so used to it that we treat it as a "minor" inconvenience. It's fundamentally a scaling issue both in the code ecosystem space (rubygems) and in the application space. As you noted, it's not just a problem that "my constant collides with your constant with the same name". It's that _every_ pair of collaborators in an application (every pair of gems in the `Gemfile`, plus every contributor to the application itself) have to follow a contract that says nobody will modify the same namespace in "unexpected" ways. When you start scaling things up, to an application with thousands of contributors with hundreds of gems, this becomes problematic at best. I think Im is a potential solution to this problem. Moreover, allaying I think some of the concerns expressed here, a gem can opt to offer two "endpoints", one for Zeitwerk and one for Im, such that the gem consumer can decide how to "consume" the gem code (either at toplevel or under an anonymous-rooted namespace). So if you like your universe always pointing to the same toplevel, it would be possible to keep that, whereas others who want to "relativize" the toplevel would also be able to do that. In any case, I don't really feel the need for further changes to Ruby other than any supporting the existing functionality in 3.2. I'm happy if this is closed, unless others want to keep it open. ---------------------------------------- Feature #19024: Proposal: Import Modules https://bugs.ruby-lang.org/issues/19024#change-101935 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- There is no general way in Ruby to load code outside of the globally-shared namespace. This makes it hard to isolate components of an application from each other and from the application itself, leading to complicated relationships that can become intractable as applications grow in size. The growing popularity of a gem like [Packwerk](https://github.com/shopify/packwerk), which provides a new concept of "package" to enforce boundaries statically in CI, is evidence that this is a real problem. But introducing a new packaging concept and CI step is at best only a partial solution, with downsides: it adds complexity and cognitive overhead that wouldn't be necessary if Ruby provided better packaging itself (as Matz has suggested [it should](https://youtu.be/Dp12a3KGNFw?t=2956)). There is _one_ limited way in Ruby currently to load code without polluting the global namespace: `load` with the `wrap` parameter, which as of https://bugs.ruby-lang.org/issues/6210 can now be a module. However, this option does not apply transitively to `require` calls within the loaded file, so its usefulness is limited. My proposal here is to enable module imports by doing the following: 1. apply the `wrap` module namespace transitively to `require`s inside the loaded code, including native extensions (or provide a new flag or method that would do this), 2. make the `wrap` module the toplevel context for code loaded under it, so `::Foo` resolves to `<top_wrapper>::Foo` in loaded code (or, again, provide a new flag or method that would do this). _Also make this apply when code under the wrapper module is called outside of the load process (when `top_wrapper` is no longer set) — this may be quite hard to do_. 3. resolve `name` on anonymous modules under the wrapped module to their names without the top wrapper module, so `<top_wrapper>::Foo.name` evaluates to `"Foo"`. There may be other ways to handle this problem, but a gem like Rails uses `name` to resolve filenames and fails when anonymous modules return something like `#<Module: ...>::ActiveRecord` instead of just `ActiveRecord`. I have roughly implemented these three things in [this patch](https://github.com/ruby/ruby/compare/master...shioyama:ruby:import_m…. This implementation is incomplete (it does not cover the last highlighted part of 2) but provides enough of a basis to implement an `import` method, which I have done in a gem called [Im](https://github.com/shioyama/im). Im provides an `import` method which can be used to import gem code under a namespace: ```ruby require "im" extend Im active_model = import "active_model" #=> <#Im::Import root: active_model> ActiveModel #=> NameError active_model::ActiveModel #=> ActiveModel active_record = import "active_record" #=> <#Im::Import root: active_record> # Constants defined in the same file under different imports point to the same objects active_record::ActiveModel == active_model::ActiveModel #=> true ``` With the constants all loaded under an anonymous namespace, any code importing the gem can name constants however it likes: ```ruby class Post < active_record::ActiveRecord::Base end AR = active_record::ActiveRecord Post.superclass #=> AR::Base ``` Note that this enables the importer to completely determine the naming for every constant it imports. So gems can opt to hide their dependencies by "anchoring" them inside their own namespace, like this: ```ruby # in lib/my_gem.rb module MyGem dep = import "my_gem_dependency" # my_gem_dependency is "anchored" under the MyGem namespace, so not exposed to users # of the gem unless they also require it. MyGemDependency = dep #... end ``` There are a couple important implementation decisions in the gem: 1. _Only load code once._ When the same file is imported again (either directly or transitively), "copy" constants from previously imported namespace to the new namespace using a registry which maps which namespace (import) was used to load which file (as shown above with activerecord/activemodel). This is necessary to ensure that different imports can "see" shared files. A similar registry is used to track autoloads so that they work correctly when used from imported code. 2. Toplevel core types (`NilClass`, `TrueClass`, `FalseClass`, `String`, etc) are "aliased" to constants under each import module to make them available. Thus there can be side-effects of importing code, but this allows a gem like Rails to monkeypatch core classes which it needs to do for it to work. 3. `Object.const_missing` is patched to check the caller location and resolve to the constant defined under an import, if there is an import defined for that file. To be clear: **I think 1) should be implemented in Ruby, but not 2) and 3).** The last one (`Object.const_missing`) is a hack to support the case where a toplevel constant is referenced from a method called in imported code (at which point the `top_wrapper` is not active.) I know this is a big proposal, and there are strong opinions held. I would really appreciate constructive feedback on this general idea. Notes from September's Developers Meeting: https://github.com/ruby/dev-meeting-log/blob/master/DevMeeting-2022-09-22.m… See also similar discussion in: https://bugs.ruby-lang.org/issues/10320 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112477] [Ruby master Bug#19448] [Hash] Using Set as default value
by bobanj (Boban Jovanoski) 18 Feb '23

18 Feb '23

Issue #19448 has been reported by bobanj (Boban Jovanoski). ---------------------------------------- Bug #19448: [Hash] Using Set as default value https://bugs.ruby-lang.org/issues/19448 * Author: bobanj (Boban Jovanoski) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When using a hash and set is used as a default value, the keys method for the hash does not return expected values. A workaround for this is provided in the attachment. ---Files-------------------------------- bug.rb (382 Bytes) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:112482] [Ruby master Feature#18597] Strings need a named method like `dup` that doesn't duplicate if receiver is mutable
by danh337 (Dan H) 17 Feb '23

17 Feb '23

Issue #18597 has been updated by danh337 (Dan H). rubyFeedback (robert heiler) wrote in #note-18: > > And it feels like I cannot convince anyone here with any amount of rationale > > Ultimately you only have to convince matz, so you could ignore what others write. > > But one reason why there was a reference to real-needs above is that the ruby > core/dev team said that they focus on real needs (although they may evaluate > what is real and what is not ultimately, as well as the cost of addition of > methods). > > My personal opinion is that, usage aside, the .dup_if_immutable feels very clunky. > [...] This is a great response, cheers and thanks for your time. Honestly I never thought this was a huge thing, and in fact we already fixed it with the "thaw" method I mentioned in comment #13 above. It was an issue that came up for me, integrating with old code, in a couple different ways, but the team considers it solved now. I think I confused the issue early on, not clearly describing the issue for Strings first, then generalizing to Object. As usual the Ruby community has some cool and helpful folks, thanks again for responding here. ---------------------------------------- Feature #18597: Strings need a named method like `dup` that doesn't duplicate if receiver is mutable https://bugs.ruby-lang.org/issues/18597#change-101925 * Author: danh337 (Dan H) * Status: Open * Priority: Normal ---------------------------------------- This is related to #16295, but focuses only on the `.+@` part. Currently we can use `.dup` in a method chain when we need to mutate a String. However there are cases where the code's context *expects* the String to be mutated. In cases like this, `.dup` always works, but we don't want to duplicate a String that is already mutable. Since `.+@` looks more like an operator, it can be unintuitive in a method chain, so this is asking for a new named method that can be used in its place, instead of always `.dup`. For example: ``` def add_result_text(buffer, new_result) text = "#{new_result.count} #{new_result.input} #{do_fancy_calc(new_result)}\n" buffer.dup_if_immutable << text # ^^^^^^^^^^^^^^^^ new method? end buffer = "" # ...maybe immutable get_lots_of_results.each do |result| buffer = add_result_text(buffer, result) # In case it was dup'ed end ``` ---Files-------------------------------- driver.rb (12.3 KB) driver.rb (12.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112480] [Ruby master Bug#19449] en-us
by Kongpcmail (KAMPANAT THUMWONG) 17 Feb '23

17 Feb '23

Issue #19449 has been reported by Kongpcmail (KAMPANAT THUMWONG). ---------------------------------------- Bug #19449: en-us https://bugs.ruby-lang.org/issues/19449 * Author: Kongpcmail (KAMPANAT THUMWONG) * Status: Open * Priority: Normal * ruby -v: -vomm * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- KAMPANAT THUMWONG ---Files-------------------------------- FFX for Families.en.txt (941 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112476] [Ruby master Bug#19041] Weakref is still alive after major garbage collection
by parker (Parker Finch) 17 Feb '23

17 Feb '23

Issue #19041 has been updated by parker (Parker Finch). File manifest_weakref_issue.rb added Hi @tenderlovemaking! I'm having difficulty interpreting the results of the `ObjectSpace` dump and I'm hoping you can help. I've adjusted the script to print out the address of the underlying object, and then (when the issue manifests) print all lines from `ObjectSpace.dump_all` that match that address. The code is attached, here's some example output: ``` Ruby version: 3.3.0 Iteration: 0 Object address: 0x1051cd788 Inner iterations: 1 Iteration: 1 Object address: 0x105205ae8 Inner iterations: 1 Inner iterations: 2 Inner iterations: 3 {"address":"0x105205ae8", "type":"OBJECT", "shape_id":5, "slot_size":40, "class":"0x1029bfe80", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} {"address":"0x10520da90", "type":"STRING", "shape_id":0, "slot_size":40, "class":"0x1029beda0", "embedded":true, "bytesize":11, "value":"0x105205ae8", "encoding":"UTF-8", "coderange":"7bit", "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} ``` In that example, the underlying object was at `0x105205ae8`. But as far as I can tell, there's nothing else that points at it. (The other object there is the String used to hold that address.) I would have expected that, if nothing was referencing it, it would be collected by GC. One interesting tidbit is that just calling `ObjectSpace.dump_all` prevents the issue from manifesting. Is it possible that something _was_ referencing the object address, then running `dump_all` caused that reference to be removed? ---------------------------------------- Bug #19041: Weakref is still alive after major garbage collection https://bugs.ruby-lang.org/issues/19041#change-101919 * Author: parker (Parker Finch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I am able to get into an infinite loop waiting for garbage collection to take a WeakRef. ### Reproduction Process The following script prints a "0", then a "1", and then hangs forever. I expect it to keep printing numbers. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) GC.start while obj.weakref_alive? iterations += 1 end ``` ### Ruby Version I have tested this on Ruby 3.1.2, 3.1.0, 3.0.4, 3.0.0, 2.7.6, and 2.7.0 on macOS. All exhibit this behavior. ### Further Investigation #### Sleeping Sleeping before the garbage collection allows the loop to continue. The below exhibits the expected behavior: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (sleep(0.5); GC.start) while obj.weakref_alive? iterations += 1 end ``` However, sleeping _after_ the garbage collection still shows the buggy behavior (loop hangs): ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (GC.start; sleep(0.5)) while obj.weakref_alive? iterations += 1 end ``` #### Running Garbage Collection Multiple Times Explicitly running garbage collection multiple times allows the loop to continue. This has the expected behavior, more numbers continue to be printed: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) while obj.weakref_alive? GC.start GC.start GC.start end iterations += 1 end ``` However, with certain rubies, running those garbage collection calls in a `times` block prevents even a single iteration from completing. The following prints only "0" with ruby 3.0.4 on macOS, ruby 2.7.6 on macOS, and ruby 3.1.2 on linux (`ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]` on a virtual machine). It shows the expected behavior on ruby 3.1.2 on macOS. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) 3.times { GC.start } while obj.weakref_alive? iterations += 1 end ``` ---Files-------------------------------- manifest_weakref_issue.rb (1.52 KB) -- https://bugs.ruby-lang.org/

1 0