December 2022 - ruby-core - ml.ruby-lang.org

[ruby-core:111308] [Ruby master Bug#19237] Hash default_proc is not thread-safe to lazy-initialize value for a given key

by Eregon (Benoit Daloze)

Issue #19237 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19237: Hash default_proc is not thread-safe to lazy-initialize value for a given key https://bugs.ruby-lang.org/issues/19237 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- ```ruby 1000.times do h = Hash.new do |hash, key| # Note, with [] instead of Array.new below is seems to work # but then e.g. anything else in this block like Thread.pass also breaks it hash[key] = Array.new end go = false threads = 100.times.map do Thread.new do Thread.pass until go h[:na] << true end end go = true threads.each(&:join) raise "Expected 100 elements but was #{h[:na].size}" if h[:na].size != 100 end ``` gives (in 3 runs): ``` concurrent_hash_default_proc.rb:17:in `block in <main>': Expected 100 elements but was 1 (RuntimeError) concurrent_hash_default_proc.rb:17:in `block in <main>': Expected 100 elements but was 3 (RuntimeError) concurrent_hash_default_proc.rb:17:in `block in <main>': Expected 100 elements but was 2 (RuntimeError) ``` So what happens is the same Hash entry gets assigned multiple times, which feels quite unexpected and cause fairly surprising bugs (e.g. elements "disappearing" etc). Any thoughts on how to solve that in CRuby? In my PhD thesis one way I found is to actually pass a different object than the Hash itself as the first argument to the block. See https://eregon.me/blog/assets/research/thesis-thread-safe-data-representati… page 83 `Idiomatic Concurrent Hash Operations`. In short, it replaces `[]=` calls in the initializer block with `put_if_absent` by passing a different object than the Concurrent::Hash itself, which overrides `[]=` and delegates the rest. #19069 could be another way but there are compatibility issues (e.g. storing when it previously would not for `Hash.new { |h,k| k * 3 }`. There is also the question whether the block should be allowed to execute more than once for a given key. I think that is difficult to solve (probably the only way is via some lock, but then that can lead to deadlocks), and less important than ensuring the value is only assigned once for a given key. --- Note that concurrent-ruby has the same issue because it uses ::Array/::Hash on CRuby: https://github.com/ruby-concurrency/concurrent-ruby/issues/970#issuecomment… There is also more discussions about trade-offs there which apply to `Hash` too. -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:111339] [Ruby master Feature#19245] Strict mode for Array#pack that doesn't silently truncate numbers that are too large for the given directive

by byroot (Jean Boussier)

Issue #19245 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #19245: Strict mode for Array#pack that doesn't silently truncate numbers that are too large for the given directive https://bugs.ruby-lang.org/issues/19245 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ```ruby >> [256].pack("C").unpack1("C") => 0 >> [257].pack("C").unpack1("C") => 1 ``` This is specified: ```ruby it "encodes the least significant 32 bits of a negative number" do [ [[-0x0000_0021], "\xdf\xff\xff\xff"], [[-0x0000_4321], "\xdf\xbc\xff\xff"], [[-0x0065_4321], "\xdf\xbc\x9a\xff"], [[-0x7865_4321], "\xdf\xbc\x9a\x87"] ].should be_computed_by(:pack, pack_format()) end ``` But not documented in `Array#pack`. I think that in many case this may lead to silent bugs. ### Possible solutions We could have a strict version of `pack`, either `pack(template, strict: true)` or `pack!(template)`. Or alternatively if we think this is never a desired behavior, we could change `pack` to first warn on truncation and later raise. -- https://bugs.ruby-lang.org/

1 year, 3 months

5
7
0 0

[ruby-core:111446] [Ruby master Misc#19265] please remove rust yjit

by darkspy (gerty ken)

Issue #19265 has been reported by darkspy (gerty ken). ---------------------------------------- Misc #19265: please remove rust yjit https://bugs.ruby-lang.org/issues/19265 * Author: darkspy (gerty ken) * Status: Open * Priority: Normal ---------------------------------------- my job is heavily ruby coding and following ruby new versions.(servers and business depend on ruby, like heavy java server clusters) my one part of job is compile and customizing ruby for use in company. it's works ok until 3.1.x but 3.2 changes yjit to rust. that means i need to learn new lang and download new toolchains to build ruby(still, it can ignoring build yjit), but we core team using yjit for monthes and can't handle code out of c/c++ especially rust. it's too ugly to acceptable(syntax and compile time, sorry to say that, but it's true for us) please consider our advices to remove rust code to c++(if u think c99 is hard to handle) or zig or any other faster lang, but no rust please. for now we just try to back port 3.1 yjit to 3.2 :( thanks, regards. Ken -- https://bugs.ruby-lang.org/

1 year, 3 months

3
2
0 0

[ruby-core:111435] [Ruby master Bug#19262] Segmentation fault on RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location

by ksss (Yuki Kurihara)

Issue #19262 has been reported by ksss (Yuki Kurihara). ---------------------------------------- Bug #19262: Segmentation fault on RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location https://bugs.ruby-lang.org/issues/19262 * Author: ksss (Yuki Kurihara) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- It seems that `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location` gives a Segmentation fault if any argument other than `Thread::Backtrace::Location` is given. repro: ``` $ ruby -e 'RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(1)' ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:111361] [Ruby master Bug#19248] TestGCCompact#test_moving_objects_between_size_pools test failure

by vo.x (Vit Ondruch)

Issue #19248 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19248: TestGCCompact#test_moving_objects_between_size_pools test failure https://bugs.ruby-lang.org/issues/19248 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-21 master 6af6857ecf) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Testing on Fedora Rawhide with commit:git|6af6857ecf, I observe the following error: ~~~ 1) Error: TestGCCompact#test_moving_objects_between_size_pools: NoMethodError: undefined method `>=' for nil:NilClass /builddir/build/BUILD/ruby-3.2.0-6af6857ecf/test/ruby/test_gc_compact.rb:278:in `<main>' /builddir/build/BUILD/ruby-3.2.0-6af6857ecf/test/ruby/test_gc_compact.rb:256:in `test_moving_objects_between_size_pools' /builddir/build/BUILD/ruby-3.2.0-6af6857ecf/tool/test/runner.rb:23:in `<top (required)>' /builddir/build/BUILD/ruby-3.2.0-6af6857ecf/test/runner.rb:16:in `require_relative' /builddir/build/BUILD/ruby-3.2.0-6af6857ecf/test/runner.rb:16:in `<main>' ~~~ Testing previously with commit:git|11acb7f7bc, everything was fine. I might just guess that this is related to commit:git|bfc66e07b7e0134dfa2041c311dc56941fe1caf0 -- https://bugs.ruby-lang.org/

1 year, 3 months

6
24
0 0

[ruby-core:111456] [Ruby master Bug#19271] irb ignores rbs and debug with YJIT enabled

by olivierlacan (Olivier Lacan)

Issue #19271 has been reported by olivierlacan (Olivier Lacan). ---------------------------------------- Bug #19271: irb ignores rbs and debug with YJIT enabled https://bugs.ruby-lang.org/issues/19271 * Author: olivierlacan (Olivier Lacan) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Not sure this is a serious issue but when starting IRB with YJIT enabled this (potentially confusing) message is immediately printed: ``` $ RUBY_YJIT_ENABLE=1 irb Ignoring debug-1.7.1 because its extensions are not built. Try: gem pristine debug --version 1.7.1 Ignoring rbs-2.8.2 because its extensions are not built. Try: gem pristine rbs --version 2.8.2 irb(main):001:0> ``` This is on a fresh installation of Ruby 3.2.0 with an empty Gemfile in the directory. I haven't run gem pristine on any gem since I hadn't installed any gems after installing Ruby 3.2.0 here but FYI: ``` $ gem list | grep "rbs\|debug" debug (1.7.1) rbs (2.8.2) ``` This seems to suggest that C extensions weren't built for those gems when they were installed during the Ruby installation process. Just to be safe I checked and while I do use rbenv and ruby-build to compile and manage Rubies, I don't have a default gem installer set up so as far as I know these gems weren't installed by my system. -- https://bugs.ruby-lang.org/

1 year, 3 months

6
8
0 0

[ruby-core:111441] [Ruby master Bug#19264] Backport 9f2378959e5c5b5c39c9993f1a84e5304ff113d6

by nagachika (Tomoyuki Chikanaga)

Issue #19264 has been reported by nagachika (Tomoyuki Chikanaga). ---------------------------------------- Bug #19264: Backport 9f2378959e5c5b5c39c9993f1a84e5304ff113d6 https://bugs.ruby-lang.org/issues/19264 * Author: nagachika (Tomoyuki Chikanaga) * Status: Closed * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- This is a ticket for backport management. 9f2378959e5c5b5c39c9993f1a84e5304ff113d6 may need to be backported. https://github.com/ruby/ruby/pull/7023 -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:111318] [Ruby master Misc#19240] DevMeeting-2023-01-19

by mame (Yusuke Endoh)

Issue #19240 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19240: DevMeeting-2023-01-19 https://bugs.ruby-lang.org/issues/19240 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/01/19 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/01/16. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

1 year, 3 months

10
13
0 0

[ruby-core:111400] [Ruby master Bug#19254] Enabling YJIT configuration option breaks rspec-core test suite

by vo.x (Vit Ondruch)

Issue #19254 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19254: Enabling YJIT configuration option breaks rspec-core test suite https://bugs.ruby-lang.org/issues/19254 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-12-23 master c5eefb7f37) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- In preparation for Ruby 3.2, we have enabled YJIT in Fedora: https://src.fedoraproject.org/rpms/ruby/c/3c1be9f9c2c1d8679eebb9a185fefa15b… Since that moment, rspec-core test suite started to fail (see the attached log for all details): ~~~ ... snip ... 1) RSpec::Core::Example#run memory leaks, see GH-321, GH-1921 releases references to the examples / their ivars Failure/Error: expect(get_all.call).to eq opts.fetch(:post_gc) expected: [] got: ["after_all", "before_all"] (compared using ==) # ./spec/rspec/core/example_spec.rb:469:in `expect_gc' # ./spec/rspec/core/example_spec.rb:492:in `block (4 levels) in <top (required)>' # ./spec/support/sandboxing.rb:16:in `block (3 levels) in <top (required)>' # ./spec/support/sandboxing.rb:7:in `block (2 levels) in <top (required)>' Finished in 8.98 seconds (files took 0.47612 seconds to load) 2209 examples, 1 failure, 4 pending ~~~ Please note that the YJIT was not enabled during runtime, just the support was enabled. Disabling the YJIT supports makes the test case pass. [1]: https://download.copr.fedorainfracloud.org/results/vondruch/ruby-3.2/fedora… [2]: https://copr.fedorainfracloud.org/coprs/vondruch/ruby-3.2/package/rubygem-r… ---Files-------------------------------- builder-live.log.gz (28.7 KB) -- https://bugs.ruby-lang.org/

1 year, 3 months

5
6
0 0

[ruby-core:111434] [Ruby master Feature#19261] `Data#members` is not important

by ko1 (Koichi Sasada)

Issue #19261 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #19261: `Data#members` is not important https://bugs.ruby-lang.org/issues/19261 * Author: ko1 (Koichi Sasada) * Status: Open * Priority: Normal ---------------------------------------- `Data#members` is defined but it is calculated by `self.class.members` (in other words, `#members` is a shorthand for `self.class.members`). So it is better to remove this method. ```ruby P = Data.define(:x, :y) p P.new(1, 2).members #=> [:x, :y] Group = Data.define(:name, :members) gs = Group.new('SasadaFamily', %w(ko1 yuki)) p gs.members #=> ["ko1", "yuki"] ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

4
4
0 0

2024

2023

2022

ruby-core December 2022