September 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119074] [Ruby master Bug#20716] Different instance_method behavior in Ruby 2.7 and Ruby 3.x
by natton (Tien Truong) 04 Nov '24

04 Nov '24

Issue #20716 has been reported by natton (Tien Truong). ---------------------------------------- Bug #20716: Different instance_method behavior in Ruby 2.7 and Ruby 3.x https://bugs.ruby-lang.org/issues/20716 * Author: natton (Tien Truong) * Status: Open * ruby -v: 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hi, I am working on upgrading our project from 2.7 to 3.x and found a breaking change in `instance_method` behavior. Here is the code snippet ``` module A def test(*args) super end end module B def test(a) puts a end end B.prepend(A) a = lambda do puts 'lambda' end class C include B end B.instance_method(:test).bind(C.new).call(1) # Ruby 2.7: 1 # Ruby 3.0: 1 # Ruby 3.1: 1 B.module_exec do define_method(:test, a) end B.instance_method(:test).bind(C.new).call # Ruby 2.7: lambda # Ruby 3.0: wrong number of arguments (given 0, expected 1) (ArgumentError) # Ruby 3.1: wrong number of arguments (given 0, expected 1) (ArgumentError) ``` I don't know if this is a bug or a correct intention. My specs: - Ruby manager: rbenv - Tested on - ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x86_64-linux] - ruby 3.0.7p220 (2024-04-23 revision 724a071175) [x86_64-linux] - ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux] - ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] - ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] -- https://bugs.ruby-lang.org/

4 12

[ruby-core:119257] [Ruby master Bug#20755] IO::Buffer#transfer transfers mutable reference to String's memory but not lock ownership
by hanazuki (Kasumi Hanazuki) 04 Nov '24

04 Nov '24

Issue #20755 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #20755: IO::Buffer#transfer transfers mutable reference to String's memory but not lock ownership https://bugs.ruby-lang.org/issues/20755 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-18T02:16:22Z master 4797b0704a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `IO::Buffer.for` with a block yields a mutable IO::Buffer that shares underlying memory with a mutable String. While the block is executed, the String instance is temporarily locked and cannot be modified or frozen. If you call `#transfer` on the yielded IO::Buffer in the block, however, a mutable IO::Buffer can be escaped from the `.for` method. Through this IO::Buffer instance, you can modify the underlying String memory even after the String instance is frozen. ```irb irb(main):001> str = +'a' => "a" irb(main):002> buf = IO::Buffer.for(str) {|b| b.transfer } => #<IO::Buffer 0x00007f244d1ede98+1 EXTERNAL SLICE> ... irb(main):003> str.freeze => "a" irb(main):004> buf.set_string('b') => 1 irb(main):005> str => "b" ``` -- https://bugs.ruby-lang.org/

5 4

[ruby-core:119248] [Ruby master Bug#20752] IO::Buffer#slice fails to copy readonly flag, allowing writes into frozen String
by hanazuki (Kasumi Hanazuki) 04 Nov '24

04 Nov '24

Issue #20752 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #20752: IO::Buffer#slice fails to copy readonly flag, allowing writes into frozen String https://bugs.ruby-lang.org/issues/20752 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-18T02:16:22Z master 4797b0704a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```irb irb(main):001> RUBY_DESCRIPTION.frozen? => true irb(main):002> IO::Buffer.for(RUBY_DESCRIPTION).set_string('perl', 0, 4) (irb):2:in 'IO::Buffer#set_string': Buffer is not writable! (IO::Buffer::AccessError) from (irb):2:in '<main>' from <internal:kernel>:191:in 'Kernel#loop' from -e:1:in '<main>' irb(main):003> IO::Buffer.for(RUBY_DESCRIPTION).slice.set_string('perl', 0, 4) => 4 irb(main):004> RUBY_DESCRIPTION => "perl 3.4.0dev (2024-09-18T02:16:22Z master 4797b0704a) +PRISM [x86_64-linux]" ``` ```irb irb(main):001> IO::Buffer.for(NameError.name).slice.set_string('X', 0, 1) => 1 irb(main):002> NameError (irb):2:in '<main>': uninitialized constant NameError (XameError) from <internal:kernel>:191:in 'Kernel#loop' from -e:1:in '<main>' ``` -- https://bugs.ruby-lang.org/

6 6

[ruby-core:119095] [Ruby master Bug#20719] `Float` converts ASCII-incompatible string
by nobu (Nobuyoshi Nakada) 04 Nov '24

04 Nov '24

Issue #20719 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20719: `Float` converts ASCII-incompatible string https://bugs.ruby-lang.org/issues/20719 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- ```ruby "\u{3036}" #=> "〶" Float("\u{3036}".encode("utf-16be")) #=> 6.0 ``` While: ```ruby Integer("\u{3036}".encode("utf-16be")) #=> ASCII incompatible encoding: UTF-16BE (Encoding::CompatibilityError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117968] [Ruby master Bug#20501] ruby SEGV
by akr (Akira Tanaka) 04 Nov '24

04 Nov '24

Issue #20501 has been reported by akr (Akira Tanaka). ---------------------------------------- Bug #20501: ruby SEGV https://bugs.ruby-lang.org/issues/20501 * Author: akr (Akira Tanaka) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I encountered SEGV of ruby. ``` % ./ruby -v ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] % ./ruby t.rb t.rb:33: [BUG] Segmentation fault at 0x00007fc243696098 ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0003 p:0000 s:4294967313 e:000018 METHOD t.rb:33 c:0002 p:0022 s:0006 e:000005 EVAL t.rb:52 [FINISH] c:0001 p:0000 s:0003 E:000350 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- t.rb:52:in '<main>' t.rb:33:in 'create_no_file' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x000055a1cdc8bb9c RBP: 0x000055a1cee844b0 RSP: 0x00007ffcde5cdae0 RAX: 0x00007fc2436960a0 RBX: 0x00007fba43795f68 RCX: 0x0000000000000000 RDX: 0x000055a1cf115cf0 RDI: 0x0000000000000009 RSI: 0x00007fba28526860 R8: 0x00007fba436960a1 R9: 0x0000000000000000 R10: 0x00007fba28526860 R11: 0x0000000000000003 R12: 0x0000000000000006 R13: 0x00007fba2853b698 R14: 0x0000000d00000009 R15: 0x0000000000000b21 EFL: 0x0000000000010246 -- C level backtrace information ------------------------------------------- /home/ruby/t2/ruby/ruby(rb_print_backtrace+0x14) [0x55a1cdcae243] /home/ruby/t2/ruby/vm_dump.c:820 /home/ruby/t2/ruby/ruby(rb_vm_bugreport) /home/ruby/t2/ruby/vm_dump.c:1151 /home/ruby/t2/ruby/ruby(rb_bug_for_fatal_signal+0xf8) [0x55a1cde5abe8] /home/ruby/t2/ruby/error.c:1108 /home/ruby/t2/ruby/ruby(sigsegv+0x44) [0x55a1cdbf7864] /home/ruby/t2/ruby/signal.c:929 /lib/x86_64-linux-gnu/libc.so.6(0x7fba438f8050) [0x7fba438f8050] /home/ruby/t2/ruby/ruby(vm_exec_handle_exception+0x2ac) [0x55a1cdc8bb9c] /home/ruby/t2/ruby/vm.c:2782 ... ``` `t.rb` and the full crash report are attached. ---Files-------------------------------- t.rb (1.27 KB) crash.txt (15.8 KB) -- https://bugs.ruby-lang.org/

7 14

[ruby-core:119124] [Ruby master Bug#20723] `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler.
by ioquatix (Samuel Williams) 04 Nov '24

04 Nov '24

Issue #20723 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20723: `IO#close` is broken on Ruby 3.3+ when using the Fiber scheduler. https://bugs.ruby-lang.org/issues/20723 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.3: REQUIRED ---------------------------------------- The following program seems to work okay on Ruby 3.2 but hangs on Ruby 3.3: ```ruby #!/usr/bin/env ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'async' end require 'socket' def close_while_reading(io) thread = Thread.new do Thread.current.report_on_exception = false io.wait_readable end # Wait until the thread is blocked on read: Thread.pass until thread.status == "sleep" Async do io.close end thread.join end begin client, server = Socket.pair(:UNIX, :STREAM) close_while_reading(client) rescue => error $stderr.puts error.full_message end ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:119117] [Ruby master Bug#20721] Gem executables have a .lock file in Ruby 3.3.5
by k0kubun (Takashi Kokubun) 04 Nov '24

04 Nov '24

Issue #20721 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #20721: Gem executables have a .lock file in Ruby 3.3.5 https://bugs.ruby-lang.org/issues/20721 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: REQUIRED ---------------------------------------- With Ruby 3.3.5, every gem executable under `$prefix/bin` has a `.lock` file. This is [an unintended change](https://github.com/ruby/ruby/pull/11252#issuecomment-2337520641), which was fixed in rubygems master at https://github.com/rubygems/rubygems/pull/7939. I filed this ticket to make sure we backport that before the Ruby 3.3.6 release. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:119091] [Ruby master Bug#20718] Objects created with Data_Make_Struct and the default free function are not freed
by jcalvert (Jonathan Calvert) 04 Nov '24

04 Nov '24

Issue #20718 has been reported by jcalvert (Jonathan Calvert). ---------------------------------------- Bug #20718: Objects created with Data_Make_Struct and the default free function are not freed https://bugs.ruby-lang.org/issues/20718 * Author: jcalvert (Jonathan Calvert) * Status: Open * ruby -v: ruby 3.3.5 (2024-09-03 revision ef084cc8f4) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I discovered a memory leak when using the FFI gem prior to version 1.16 and Ruby 3.3 and up. During debugging I found that this earlier version of FFI uses Data_Make_Struct (https://github.com/ffi/ffi/blob/v1.15.5/ext/ffi_c/Pointer.c#L57) instead of TypedData_Make_Struct and it uses -1 as the free function, which is RUBY_DEFAULT_FREE When the object goes to get garbage collected, it enters into rb_data_free and it is passed to the RTYPEDDATA_EMBEDDED_P macro even though it is not of RTypedData. Because of that, the conditional is evaluated to false and xfree is never called. This was discovered by using jemalloc leak detection. I have attached a somewhat minimal replication of the issue. The fix would appear to check the type of the obj before casting it. ---Files-------------------------------- pointer_bug.rb (418 Bytes) Gemfile.txt (104 Bytes) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119121] [Ruby master Bug#20722] curious search result order on docs.ruby-lang.org
by masterleep2 (Bill Lipa) 01 Nov '24

01 Nov '24

Issue #20722 has been reported by masterleep2 (Bill Lipa). ---------------------------------------- Bug #20722: curious search result order on docs.ruby-lang.org https://bugs.ruby-lang.org/issues/20722 * Author: masterleep2 (Bill Lipa) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- If you search for "String" on https://docs.ruby-lang.org/en/3.3/ the first four results returned are obscure: 1. Gem::SafeMarshal::Elements::String 2. Prism::StringFlags 3. Prism::StringNode 4. Reline::Terminfo::StringWithTiparm 5. String Would it be possible to change it so that if one types an exact class name, the class of that name is first on the list? This would make it easier to use the search feature. More generally, the prioritization of these results is surprising. Not sure if this is the right place to report a doc website issue. Apologies if not. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118932] [Ruby master Bug#20693] Dir.tmpdir should perform a real access check before warning about writability
by kjtsanaktsidis (KJ Tsanaktsidis) 22 Oct '24

22 Oct '24

Issue #20693 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20693: Dir.tmpdir should perform a real access check before warning about writability https://bugs.ruby-lang.org/issues/20693 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The code in `Dir.tmpdir` attempts to warn the user if their temp directory is deficient for some reason: ```ruby case when !stat.directory? warn "#{name} is not a directory: #{dir}" when !stat.writable? warn "#{name} is not writable: #{dir}" when stat.world_writable? && !stat.sticky? warn "#{name} is world-writable: #{dir}" else break dir end ``` This check for writability is looking at the user/group/world access bits on the stat output, and determining if the user running Ruby is allowed to write to the temp directory based on that. However, modern operating systems contain other mechanisms apart from the user/group/world bits which can grant access to a directory that would otherwise be denied, or vice versa. Things like: * Posix ACL's * Linux's capabilities like CAP_DAC_OVERRIDE * Linux Security Modules like SELinux or AppArmor * Syscall filters like Linux's seccomp * Granular capability systems like FreeBSD's Capsicum * OpenBSD's pledge and unveil * Windows too has a rich ACL system for controlling filesystem access To address this, we should call `File.writable?` instead of `stat.writable?`, which asks the system whether the file is writable using the `euidaccess()` function if available. On Linux/glibc, at least, this will issue an `access(2)` syscall, and the Kernel can take all of the above into account. n.b. if Ruby is running as suid, then glibc currently will NOT ask the kernel to perform the access check in `euidaccess()`, and instead does a similar thing to what `Stat#writable?` does (https://github.com/bminor/glibc/blob/7f04bb4e49413bd57ac3215f3480b09ae71319…) This is because of the relatively new `faccessat2(2)` syscall is required to do this properly, and there is some ecosystem issues with leveraging this by default (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1900021) Since running Ruby as suid is probably a very bad idea anyway, and the glibc implementation isn't any worse than the `Stat#writable?` one, this seems OK though. -- https://bugs.ruby-lang.org/

4 8