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

[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

[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

[ruby-core:119352] [Ruby master Bug#20771] make-snapshot is broken with ubuntu-latest
by hsbt (Hiroshi SHIBATA) 21 Oct '24

21 Oct '24

Issue #20771 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #20771: make-snapshot is broken with ubuntu-latest https://bugs.ruby-lang.org/issues/20771 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- `make-snapshot` is broken now with the following failure. ``` Command Line Error: Unknown switch: -l creating zip archive... /home/runner/work/actions/actions/pkg/snapshot-ruby_3_3.zip 0.003 failed ``` I opened PRs to stable branches: * https://github.com/ruby/ruby/pull/11729 * https://github.com/ruby/ruby/pull/11730 * https://github.com/ruby/ruby/pull/11731 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:119168] [Ruby master Feature#20738] Removing a specific entry from a hash literal
by ursm (Keita Urashima) 09 Oct '24

09 Oct '24

Issue #20738 has been reported by ursm (Keita Urashima). ---------------------------------------- Feature #20738: Removing a specific entry from a hash literal https://bugs.ruby-lang.org/issues/20738 * Author: ursm (Keita Urashima) * Status: Open ---------------------------------------- Sometimes I want to decide whether or not to add a particular entry to a hash depending on a condition. If the entire hash does not use nil, I can use Hash#compact. ```ruby { foo: 1, bar: bar? ? 2 : nil }.compact ``` But if I want to remove only a specific entry while leaving the other nil, it is somewhat cumbersome. I have to either assign the hash once and change it destructively, or use Hash#reject. ``` ruby h = { foo: 1, baz: nil } h[:bar] = 2 if bar? ``` ``` ruby { foo: 1, bar: bar? ? 2 : :drop, baz: nil }.reject {|_, v| v == :drop } ``` As a suggestion, how about a special value that indicates an invalid key for the hash? With this, the above example could be written like this: ``` ruby { foo: 1, bar: bar? ? 2 : Hash::DROP, baz: nil } #=> {foo: 1, baz: nil} ``` -- https://bugs.ruby-lang.org/

8 15