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

[ruby-core:113266] [Ruby master Bug#19602] `PLATFORM_GET_INC` is broken unless unaligned word access is allowed

by nobu (Nobuyoshi Nakada)

Issue #19602 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19602: `PLATFORM_GET_INC` is broken unless unaligned word access is allowed https://bugs.ruby-lang.org/issues/19602 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Priority: Normal * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Please backport regint.h part of commit:git|fac814c2dc31afef272b45392a7389ef0bfa3a4f. -- https://bugs.ruby-lang.org/

9 months, 4 weeks

3
2
0 0

[ruby-core:112948] [Ruby master Bug#19543] Resizing IO::Buffer to zero bytes fails

by hanazuki (Kasumi Hanazuki)

Issue #19543 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #19543: Resizing IO::Buffer to zero bytes fails https://bugs.ruby-lang.org/issues/19543 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-03-20T04:02:21Z master 7f696b8859) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` irb(main):001:0> IO::Buffer.new(1).resize(0) /home/kasumi/.local/src/github.com/ruby/ruby/-e:1: warning: IO::Buffer is experimental and both the Ruby and C interface may change in the future! /home/kasumi/.local/src/github.com/ruby/ruby/-e:1: [BUG] rb_sys_fail(rb_io_buffer_resize:realloc) - errno == 0 ruby 3.3.0dev (2023-03-20T04:02:21Z master 7f696b8859) [x86_64-linux] # full trace is attached to this ticket ``` `IO::Buffer#resize(0)` will result in calling `realloc(data->base, size)` with size = 0 in [rb_io_buffer_resize](https://bugs.ruby-lang.org/projects/ruby-master/reposi…. Zero-sized `realloc` is deprecated in C (and will be UB in C23). ---Files-------------------------------- bug.txt (40 KB) -- https://bugs.ruby-lang.org/

9 months, 4 weeks

4
5
0 0

[ruby-core:111698] [Ruby master Bug#19318] Float#round rounds incorrectly for some cases

by Eregon (Benoit Daloze)

Issue #19318 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19318: Float#round rounds incorrectly for some cases https://bugs.ruby-lang.org/issues/19318 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- This was discovered by @aardvark179. The following spec in `spec/ruby/core/float/round_spec.rb` fails on CRuby: ```ruby ruby_bug "", ""..."3.3" do # These numbers are neighbouring floating point numbers round a # precise value. They test that the rounding modes work correctly # round that value and precision is not lost which might cause # incorrect results. it "does not lose precision during the rounding process" do 767573.1875850001.round(5, half: nil).should eql(767573.18759) 767573.1875850001.round(5, half: :up).should eql(767573.18759) 767573.1875850001.round(5, half: :down).should eql(767573.18759) 767573.1875850001.round(5, half: :even).should eql(767573.18759) -767573.1875850001.round(5, half: nil).should eql(-767573.18759) -767573.1875850001.round(5, half: :up).should eql(-767573.18759) -767573.1875850001.round(5, half: :down).should eql(-767573.18759) -767573.1875850001.round(5, half: :even).should eql(-767573.18759) 767573.187585.round(5, half: nil).should eql(767573.18759) 767573.187585.round(5, half: :up).should eql(767573.18759) 767573.187585.round(5, half: :down).should eql(767573.18758) 767573.187585.round(5, half: :even).should eql(767573.18758) -767573.187585.round(5, half: nil).should eql(-767573.18759) -767573.187585.round(5, half: :up).should eql(-767573.18759) -767573.187585.round(5, half: :down).should eql(-767573.18758) -767573.187585.round(5, half: :even).should eql(-767573.18758) 767573.1875849998.round(5, half: nil).should eql(767573.18758) 767573.1875849998.round(5, half: :up).should eql(767573.18758) 767573.1875849998.round(5, half: :down).should eql(767573.18758) 767573.1875849998.round(5, half: :even).should eql(767573.18758) -767573.1875849998.round(5, half: nil).should eql(-767573.18758) -767573.1875849998.round(5, half: :up).should eql(-767573.18758) -767573.1875849998.round(5, half: :down).should eql(-767573.18758) -767573.1875849998.round(5, half: :even).should eql(-767573.18758) end end ``` Yet this test to the best of our knowledge is correct. This was fixed on master by @mrkn in https://github.com/ruby/ruby/pull/7023 (thanks!). The question is should we backport this? I think yes. -- https://bugs.ruby-lang.org/

9 months, 4 weeks

3
2
0 0

[ruby-core:112146] [Ruby master Bug#19394] cvars in instance of cloned class point to source class's cvars even after class_variable_set on clone

by jamescdavis (James Davis)

Issue #19394 has been reported by jamescdavis (James Davis). ---------------------------------------- Bug #19394: cvars in instance of cloned class point to source class's cvars even after class_variable_set on clone https://bugs.ruby-lang.org/issues/19394 * Author: jamescdavis (James Davis) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This unexpected change in behavior happens between Ruby 3.0.x and 3.1.x. In Ruby >= 3.1, when a class with a cvar is cloned (or duped), the cvar in instances of the cloned class continues to point to the source class’s cvar after the clone has its cvar updated with `class_variable_set`. In Ruby < 3.1, the cloned class instance points to the updated cvar, as expected. It seems likely that this is a bug in the [cvar cache](https://bugs.ruby-lang.org/issues/17763) introduced in Ruby 3.1. Repro: ```rb class Foo @@bar = 'bar' def print_bar puts "#{self.class.name} (from instance): #{@@bar} #{@@bar.object_id}" end end foo_bar = Foo.class_variable_get(:@@bar) puts "Foo (class_variable_get): #{foo_bar} #{foo_bar.object_id}" Foo.new.print_bar FooClone = Foo.clone FooClone.class_variable_set(:@@bar, 'bar_clone') foo_clone_bar = FooClone.class_variable_get(:@@bar) puts "FooClone (class_variable_get): #{foo_clone_bar} #{foo_clone_bar.object_id}" FooClone.new.print_bar ``` Ruby 3.0.5: ``` Foo (class_variable_get): bar 60 Foo (from instance): bar 60 FooClone (class_variable_get): bar_clone 80 FooClone (from instance): bar_clone 80 ``` Ruby 3.1.3, 3.2.0: ``` Foo (class_variable_get): bar 60 Foo (from instance): bar 60 FooClone (class_variable_get): bar_clone 80 FooClone (from instance): bar 60 ``` Something similar happens when there are multiple clones and a cvar that the source class does not have defined is set on the clones. In this case, the cvars in instances of the clones all point to the first clone’s cvar. Repro: ```rb class Foo def print_bar puts "#{self.class.name} (from instance): #{@@bar} #{@@bar.object_id}" end end Foo1 = Foo.clone Foo2 = Foo.clone Foo3 = Foo.clone Foo1.class_variable_set(:@@bar, 'bar1') Foo2.class_variable_set(:@@bar, 'bar2') Foo3.class_variable_set(:@@bar, 'bar3') foo1_bar = Foo1.class_variable_get(:@@bar) foo2_bar = Foo2.class_variable_get(:@@bar) foo3_bar = Foo3.class_variable_get(:@@bar) puts "Foo1 (class_variable_get): #{foo1_bar} #{foo1_bar.object_id}" puts "Foo2 (class_variable_get): #{foo2_bar} #{foo2_bar.object_id}" puts "Foo3 (class_variable_get): #{foo3_bar} #{foo3_bar.object_id}" Foo1.new.print_bar Foo2.new.print_bar Foo3.new.print_bar ``` Ruby 3.0.5: ``` Foo1 (class_variable_get): bar1 60 Foo2 (class_variable_get): bar2 80 Foo3 (class_variable_get): bar3 100 Foo1 (from instance): bar1 60 Foo2 (from instance): bar2 80 Foo3 (from instance): bar3 100 ``` Ruby 3.1.3, 3.2.0: ``` Foo1 (class_variable_get): bar1 60 Foo2 (class_variable_get): bar2 80 Foo3 (class_variable_get): bar3 100 Foo1 (from instance): bar1 60 Foo2 (from instance): bar1 60 Foo3 (from instance): bar1 60 ``` -- https://bugs.ruby-lang.org/

9 months, 4 weeks

5
7
0 0

[ruby-core:113953] [Ruby master Bug#19739] Key cannot be found in a Hash when slice! method is applied to the key

by ilya.andreyuk (Ilya Andreyuk)

Issue #19739 has been reported by ilya.andreyuk (Ilya Andreyuk). ---------------------------------------- Bug #19739: Key cannot be found in a Hash when slice! method is applied to the key https://bugs.ruby-lang.org/issues/19739 * Author: ilya.andreyuk (Ilya Andreyuk) * Status: Open * Priority: Normal * ruby -v: 3.1.4 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hello, Key cannot be found in a Hash when slice! method is applied to the key. I cannot reproduce this behaviour with sub! or gsub! methods: ``` ruby hash = {} key = "ABC OÜ" key.slice!(/ oü$/i) # key.sub!(/ oü$/i, '') # key.gsub!(/ oü$/i, '') hash[key] = true "#{key} in #{hash}: value is #{hash[key]}" => "ABC in {\"ABC\"=>true}: value is " ``` Also it seems that ruby 2.7.6 and 3.2.2 don't have this issue. -- https://bugs.ruby-lang.org/

9 months, 4 weeks

4
8
0 0

[ruby-core:113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues

by postmodern (Hal Brodigan)

Issue #19630 has been reported by postmodern (Hal Brodigan). ---------------------------------------- Feature #19630: [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues https://bugs.ruby-lang.org/issues/19630 * Author: postmodern (Hal Brodigan) * Status: Open * Priority: Normal ---------------------------------------- `Kernel.open()` is the source of numerous [1] security [2] issues [3], due to the fact that it can be used to execute commands if given a String argument of the form `"|command-here"`. However, in most uses of `Kernel.open()` the developer appears to either want to open a local file, or if 'open-uri' was explicitly required open a remote URI. We should deprecate calling `Kernel.open()` with a `"|command-here"` style arguments, with a warning message instructing the developer to use `IO.popen()` instead. Eventually, support for `Kernel.open("|command-here")` could be removed completely, in favor of having the developer explicitly call `IO.popen()` or `URI.open()`. [1]: https://45w1nkv.medium.com/ruby-code-vulnerability-analysis-confirmsnssubsc… [2]: https://bishopfox.com/blog/ruby-vulnerabilities-exploits [3]: https://blog.heroku.com/identifying-ruby-ftp-cve -- https://bugs.ruby-lang.org/

10 months

11
18
0 0

[ruby-core:111565] [Ruby master Bug#19293] The new Time.new(String) API is nice... but we still need a stricter version of this

by matsuda (Akira Matsuda)

Issue #19293 has been reported by matsuda (Akira Matsuda). ---------------------------------------- Bug #19293: The new Time.new(String) API is nice... but we still need a stricter version of this https://bugs.ruby-lang.org/issues/19293 * Author: matsuda (Akira Matsuda) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-01-01T07:39:00Z master 542e984d82) +YJIT [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The Ruby 3.2 style `Time.new(String)` API works very well so far, but since the original `Time.new(Integer, Integer, Integer...)` API actually accepts String objects as its arguments, there's one ambiguous case as follows: `Time.new('20230123') #=> 20230123-01-01 00:00:00 +0900` Then the problem that I'm facing is that we cannot tell if `Time.new` would parse the given String as ISO8601-ish or just a year, and in order to avoid this ambiguity, we still need to somehow parse the String beforehand in our application side (like we're doing this way in Ruby on Rails https://github.com/rails/rails/blob/c49b8270/activemodel/lib/active_model/t…), then dispatch to the new `Time.new` only when the String is validated to be conforming the ISO format. Otherwise, if we just optimistically pass in given Strings to `Time.new`, we'll occasionally get a Time object with an unintended buggy value. Therefore, it unfortunately seems that my feature request on #16005 still continues... I have to keep proposing that we need either of the following: 1. A trustworthy version of ISO8601 parser method perhaps with another name than `.new` that accepts strict ISO8601-ish String only (but with the T delimiter, I still don't know what the proper name of this format is). 2. Change `Time.new(Integer-ish, Integer-ish, Integer-ish...)` not to accept Integer-ish Strings but to accept only Integers. But I can imagine that this direction is very unlikely acceptable, due to the incompatibility. -- https://bugs.ruby-lang.org/

10 months

7
7
0 0

[ruby-core:114034] [Ruby master Bug#19748] `String#byteindex` crashes when `offset` is too large

by nobu (Nobuyoshi Nakada)

Issue #19748 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19748: `String#byteindex` crashes when `offset` is too large https://bugs.ruby-lang.org/issues/19748 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- ```ruby "a".byteindex("", 1000000) #=> [BUG] Segmentation fault ``` -- https://bugs.ruby-lang.org/

10 months

2
1
0 0

[ruby-core:113160] [Ruby master Bug#19585] Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc

by eviljoel (evil joel)

Issue #19585 has been reported by eviljoel (evil joel). ---------------------------------------- Bug #19585: Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc https://bugs.ruby-lang.org/issues/19585 * Author: eviljoel (evil joel) * Status: Open * Priority: Normal * ruby -v: 3.2.2, 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby fails to build on macOS 12.6.4 when configured with --enable-shared and --with-jemalloc. I receive the following linking error: ``` building spec/ruby/optional/capi/ext/bignum_spec.bundle Undefined symbols for architecture x86_64: "_je_free", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o "_je_malloc", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [spec/ruby/optional/capi/ext/bignum_spec.bundle] Error 1 ``` It appears that the bignum C API spec requires "-undefined dynamic_lookup" to be enabled. I can get the build to succeed with: ``` ./configure --enable-shared --with-jemalloc DLDFLAGS='-Wl,-undefined,dynamic_lookup' ``` I’ve created several bash scripts to demonstrate that: 1) This is an error with the current production release of Ruby. Running jemallocBug-ruby3.2.2-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.2.2. 2) This is a regression in at least the Ruby 3.1 branch. Running jemallocSucceeds-ruby3.1.2-20230407.sh demonstrates that building Ruby with these parameters worked with Ruby 3.1.2 and running jemallocBug-ruby3.1.3-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.1.3. In the Ruby 3.1 branch, the first commit where this broke appears to be 2244fc9aa7ef8e03ac966e59b581baa021106b46. ld version information: ``` $ ld -v @(#)PROGRAM:ld PROJECT:ld64-820.1 BUILD 20:07:01 Nov 7 2022 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 14.0.0, (clang-1400.0.29.202) (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) $ ``` clang version information: ``` $ clang -v Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ ``` I’m using jemalloc version 5.3.0. MacBook Specs are: ``` Model: MacBook Pro (16-inch, 2019) Processor: 2.4 GHz 8-Core Intel Core i9 Memory: 32 GB 2667 MHz DDR4 Graphics: AMD Radeon Pro 5300M 4 GB and Intel UHD Graphics 630 1536 MB ``` I’ve attached the config.log and config.status for the failed Ruby 3.2.2 build. Please let me know if you need any more information. ---Files-------------------------------- jemallocSucceeds-ruby3.1.2-20230407.sh (804 Bytes) jemallocBug-ruby3.2.2-20230407.sh (804 Bytes) jemallocBug-ruby3.1.3-20230407.sh (804 Bytes) ruby-3.2.2-config.status (34.4 KB) ruby-3.2.2-config.log (1.57 MB) -- https://bugs.ruby-lang.org/

10 months

4
3
0 0

[ruby-core:112918] [Ruby master Bug#19532] Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken

by Eregon (Benoit Daloze)

Issue #19532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19532: Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken https://bugs.ruby-lang.org/issues/19532 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Fix in https://github.com/ruby/ruby/pull/7510 -- https://bugs.ruby-lang.org/

10 months

4
3
0 0

2024

2023

2022

ruby-core June 2023