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

[ruby-core:113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`.
by ioquatix (Samuel Williams) 20 Nov '24

20 Nov '24

Issue #19642 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19642: Remove vectored read/write from `io.c`. https://bugs.ruby-lang.org/issues/19642 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- https://github.com/socketry/async/issues/228#issuecomment-1546789910 is a comment from the kernel developer who tells us that `writev` is always worse than `write` system call. A large amount of complexity in `io.c` comes from optional support from `writev`. So, I'd like to remove support for `writev`. I may try to measure the performance before/after. However it may not show much difference, except that the implementation in `io.c` can be much simpler. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:111966] [Ruby master Feature#19366] Rename/alias Refinedment#refined_class => #refined_module
by zverok (Victor Shepelev) 19 Nov '24

19 Nov '24

Issue #19366 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19366: Rename/alias Refinedment#refined_class => #refined_module https://bugs.ruby-lang.org/issues/19366 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- In #12737, `Refinement#refined_class` is introduced. As "module" is more generic concept than "class", the name misleadingly implies that either this method doesn't returns refined _modules_, or modules can't be refined. This is obviously not true and trivially disproved: ```ruby module Refs refine Enumerable do def foo = puts 'foo' end end Refs.refinements[0].refined_class #=> Enumerable. Which is, well, not a class. # The refinement is usable, so it is not a mute concept: using Refs [1, 2, 3].foo # prints "foo" successfully ``` I believe we refer to "modules" when some feature applies to modules and classes. Unless there is some deeper consideration for the current naming (I don't see justification in #12737, but I might miss something), the method should be renamed or aliased. PS: Sorry for a huge amount of "nitpicky" issues after the version release. Typically, those concerns emerge while I am working on the [changelog](https://rubyreferences.github.io/rubychanges/), and I am usually trying to start the work at least a month before the release. Unfortunately, due to you-know-what, I was unable to do it in time this year. After the 3.2 changelog, I plan to switch to the "master changelog" approach (following the development with the "current unreleased changes" document) this year. Unless I'll be unable to due to reasons not in my control. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:117240] [Ruby master Feature#20350] Return chilled string from Symbol#to_s
by Dan0042 (Daniel DeLorme) 12 Nov '24

12 Nov '24

Issue #20350 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #20350: Return chilled string from Symbol#to_s https://bugs.ruby-lang.org/issues/20350 * Author: Dan0042 (Daniel DeLorme) * Status: Open ---------------------------------------- During Ruby 2.7 development there was an attempt to return a frozen string from Symbol#to_s (#16150#note-22) This had to be rolled back due to incompatibility, but now we have chilled strings (#20205) Symbol#to_s can safely return a chilled string, giving developers time to fix warnings before switching to a frozen string. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:118976] [Ruby master Bug#20704] Windows: `-C` option does not work for multibyte path name
by nobu (Nobuyoshi Nakada) 08 Nov '24

08 Nov '24

Issue #20704 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20704: Windows: `-C` option does not work for multibyte path name https://bugs.ruby-lang.org/issues/20704 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Related to [Bug #20699]. ``` C:> \Ruby33-x64\bin\ruby.exe -C xテスト_test -ep \Ruby33-x64\bin\ruby.exe: Can't chdir to xテスト_test (fatal) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:116589] [Ruby master Misc#20238] Use prism for mk_builtin_loader.rb
by kddnewton (Kevin Newton) 05 Nov '24

05 Nov '24

Issue #20238 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20238: Use prism for mk_builtin_loader.rb https://bugs.ruby-lang.org/issues/20238 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose that we use prism for mk_builtin_loader.rb. Right now the Ruby syntax that you can use in builtin classes is restricted to the base Ruby version (2.7). This means you can't use a lot of the nicer syntax that Ruby has shipped in the last couple of years. If we switch to using prism to parse the builtin files instead of using ripper, then we can always use the latest version of Ruby syntax. A pull request for this is here: https://github.com/kddnewton/ruby/pull/65. The approach for the PR is taken from how RJIT bindgen works. -- https://bugs.ruby-lang.org/

6 21

[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: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

[ruby-core:112058] [Ruby master Bug#19383] Time.now.zone encoding for German display language in Windows is incorrect
by stringsn88keys (Thomas Powell) 21 Oct '24

21 Oct '24

Issue #19383 has been reported by stringsn88keys (Thomas Powell). ---------------------------------------- Bug #19383: Time.now.zone encoding for German display language in Windows is incorrect https://bugs.ruby-lang.org/issues/19383 * Author: stringsn88keys (Thomas Powell) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- OS: Verified on Windows 10 and Windows Server 2022 and Ruby 2.7.7 through 3.1.3 Display language: Verified on German, but may impact other languages in which Time.now.zone returns characters that aren't [A-Za-z]. Time zone: CET (UTC +01:00) Amsterdam, Berlin, ... Time.now.zone # => "Mitteleuro\xE3ische Zeit" Time.now.zone.encoding # => #<Encoding:IBM437> puts Time.now.zone # => "Mitteleurop∑ische Zeit" (should be "Mitteleuropäische Zeit") Time.now.zone.encode(Encoding::UTF_8) # => "Mitteleurop∑ische Zeit" Doing a force_encoding on all encodings in Encoding.list reveals that ISO-8859-(1..16) and Windows-125(0,2,4,7) work to coerce the ä out of the time zone string: Time.now.zone.force_encoding(Encoding::WINDOWS_1252) # => "Mitteleuro\xE3ische Zeit" ... but ... Time.now.zone.force_encoding(Encoding::WINDOWS_1252).encode(Encoding::UTF_8) #=> "Mitteleuropäische Zeit" Related issue: This improper encoding/rendering caused Ohai's JSON output to be unparseable. Workaround was forcing to Windows-1252. https://github.com/chef/ohai/pull/1781 -- https://bugs.ruby-lang.org/

5 10

[ruby-core:117957] [Ruby master Bug#20500] Non-system directories are not searched when checking for jemalloc headers and libs, and building `enc`
by lish82 (Hiroki Katagiri) 21 Oct '24

21 Oct '24

Issue #20500 has been reported by lish82 (Hiroki Katagiri). ---------------------------------------- Bug #20500: Non-system directories are not searched when checking for jemalloc headers and libs, and building `enc` https://bugs.ruby-lang.org/issues/20500 * Author: lish82 (Hiroki Katagiri) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a problem similar to #20494 on jemalloc It's similar to #20494, but it has a few more issues Problems: - Non-system directories (specified by `--with-opt-dir`) are not searched when checking jemalloc headers (almost the same as #20494) - Non-system directories are not searched when checking jemalloc libs - Non-system directories are not searched when building the `enc` directory sources I have confirmed that this problem can be fixed by applying the following patch: ```patch diff --git a/configure.ac b/configure.ac index 169662c..b2dce70 100644 --- a/configure.ac +++ b/configure.ac @@ -1392,6 +1392,8 @@ AC_ARG_WITH([jemalloc], [with_jemalloc=$withval], [with_jemalloc=no]) AS_IF([test "x$with_jemalloc" != xno],[ # find jemalloc header first + save_CPPFLAGS="${CPPFLAGS}" + CPPFLAGS="${INCFLAGS} ${CPPFLAGS}" malloc_header= AC_CHECK_HEADER(jemalloc/jemalloc.h, [malloc_header=jemalloc/jemalloc.h], [ AC_CHECK_HEADER(jemalloc.h, [malloc_header=jemalloc.h]) @@ -1423,6 +1425,8 @@ AS_IF([test "x$with_jemalloc" != xno],[ done done ]) + CPPFLAGS="${save_CPPFLAGS}" + unset save_CPPFLAGS with_jemalloc=${rb_cv_jemalloc_library} AS_CASE(["$with_jemalloc"], [no], diff --git a/enc/Makefile.in b/enc/Makefile.in index 6920bc9..ce93fdd 100644 --- a/enc/Makefile.in +++ b/enc/Makefile.in @@ -52,7 +52,7 @@ optflags = @optflags@ debugflags = @debugflags@ warnflags = @warnflags@ CCDLFLAGS = @CCDLFLAGS@ -INCFLAGS = -I. -I$(arch_hdrdir) -I$(hdrdir) -I$(top_srcdir) +INCFLAGS = -I. -I$(arch_hdrdir) -I$(hdrdir) -I$(top_srcdir) @incflags@ DEFS = @DEFS@ CPPFLAGS = @CPPFLAGS@ -DONIG_ENC_REGISTER=rb_enc_register LDFLAGS = @LDFLAGS@ ``` --- On a side note, I think there might be other parts affected by the changes bellow: https://github.com/ruby/ruby/pull/8449 I thought it might be a good idea to review everything thoroughly -- https://bugs.ruby-lang.org/

5 11

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 21 Oct '24

21 Oct '24

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 4