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

[ruby-core:116183] [Ruby master Bug#20181] Process.wait(-1) doesn't report exited child processes if WAITPID_USE_SIGCHLD is enabled
by stanhu (Stan Hu) 13 Jan '24

13 Jan '24

Issue #20181 has been reported by stanhu (Stan Hu). ---------------------------------------- Bug #20181: Process.wait(-1) doesn't report exited child processes if WAITPID_USE_SIGCHLD is enabled https://bugs.ruby-lang.org/issues/20181 * Author: stanhu (Stan Hu) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- From Ruby 2.6 to 3.2, `Process.wait(-1)` doesn't return in a timely manner if a spawned, detached process is still running. The following script exits immediately with Ruby 3.3, but hangs for 10 minutes (the length of the `sleep`) in Ruby 2.6 to 3.2: ```ruby #!/bin/env ruby Process.spawn({}, "sh -c 'sleep 600'").tap do |pid| puts "detaching PID #{pid}" Process.detach(pid) end forked_pid = fork do loop { sleep 1 } end child_waiter = Thread.new do puts "Waiting for child process to die..." # This works # puts Process.wait2(forked_pid) # The spawned process has to exit before this returns in Ruby 3.1 and 3.2 pid, status = Process.wait2(-1) puts "Exited PID: #{pid}, status: #{status}" end process_killer = Thread.new do puts "Killing #{forked_pid}" system("kill #{forked_pid}") end child_waiter.join process_killer.join ``` In Ruby 3.2, we see: ``` detaching PID 8 Waiting for child process to die... Killing 11 <process hangs here> ``` In Ruby 3.3, this exits immediately: ``` detaching PID 9 Waiting for child process to die... Killing 11 Exited PID: 11, status: pid 11 SIGTERM (signal 15) ``` However, if I switch the `Process.wait(-1)` to `Process.wait(forked_pid)`, Ruby 3.2 works fine. I've validated that this problem goes away if I disable `WAITPID_USE_SIGCHLD`: ```diff diff --git a/vm_core.h b/vm_core.h index 1cc0659700..0e7d1643fe 100644 --- a/vm_core.h +++ b/vm_core.h @@ -126,7 +126,7 @@ #endif /* define to 0 to test old code path */ -#define WAITPID_USE_SIGCHLD (RUBY_SIGCHLD || SIGCHLD_LOSSY) +#define WAITPID_USE_SIGCHLD 0 #if defined(SIGSEGV) && defined(HAVE_SIGALTSTACK) && defined(SA_SIGINFO) && !defined(__NetBSD__) # define USE_SIGALTSTACK ``` This was first reported in the Puma issue tracker (https://github.com/puma/puma/issues/3313) and another contributor documented long-standing issues with `Process.wait` in the past: https://github.com/dentarg/gists/tree/master/gists/ruby-bug-15499#ruby--pum… In Ruby 2.6, https://github.com/ruby/ruby/commit/054a412d540e7ed2de63d68da753f585ea6616c3 introduced a mechanism for `rb_waitpid` that uses `SIGCHLD` for blocking `wait` calls, and this might have introduced this bug. Ruby 2.5 doesn't appear to have this problem. In Ruby 3.3, this `SIGCHLD` implementation was dropped in https://github.com/ruby/ruby/pull/7476 and https://github.com/ruby/ruby/pull/7527, so Ruby 3.3 no longer appears affected. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115181] [Ruby master Bug#19975] ISeq#to_binary loses hidden local variable indices
by kddnewton (Kevin Newton) 12 Jan '24

12 Jan '24

Issue #19975 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #19975: ISeq#to_binary loses hidden local variable indices https://bugs.ruby-lang.org/issues/19975 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When you call `RubyVM::InstructionSequence#to_a`, you get hidden local variables as the index in the stack from the top: ``` c if (rb_id2str(lid)) { rb_ary_push(locals, ID2SYM(lid)); } else { /* hidden variable from id_internal() */ rb_ary_push(locals, ULONG2NUM(iseq_body->local_table_size-i+1)); } ``` ``` rb RubyVM::InstructionSequence.compile("for foo in bar; end").to_a[13][4][2][10] # => [2] ``` When you call `RubyVM::InstructionSequence#to_binary`, it dumps hidden local variables as 0: ``` c if (id == 0 || rb_id2name(id) == NULL) { return 0; } return ibf_dump_object(dump, rb_id2sym(id)); ``` When it reads that back in and then you call `to_a`, you get `:#arg_rest`: ``` ruby RubyVM::InstructionSequence.load_from_binary(RubyVM::InstructionSequence.compile("for foo in bar; end").to_binary).to_a[13][4][2][10] # => [:"#arg_rest"] ``` This means you end up not being able to consistently look at the locals. Instead, when reading back in from binary it could replace it with the index so that it matches up with the value before it is dumped to binary. Could we do that so that `#to_a` is consistent no matter where the iseq came from? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116180] [Ruby master Bug#20179] `--with-ruby-version` configure option is not correctly applied to `rubyhdrdir`
by vo.x (Vit Ondruch) 12 Jan '24

12 Jan '24

Issue #20179 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20179: `--with-ruby-version` configure option is not correctly applied to `rubyhdrdir` https://bugs.ruby-lang.org/issues/20179 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am trying to configure ruby using `--with-ruby-version=ruby3.3`. Here is the configure output: ~~~ $ /builddir/build/BUILD/ruby-3.3.0/configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --runstatedir=/run --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-compress-debug-sections=no --disable-rpath --enable-mkmf-verbose --enable-shared --with-ruby-version=ruby3.3 --enable-yjit ... snip ... --- Configuration summary for ruby version 3.3.0 * Installation prefix: /usr * exec prefix: /usr * arch: x86_64-linux * site arch: ${arch} * RUBY_BASE_NAME: ruby * enable shared: yes * ruby lib prefix: ${libdir}/${RUBY_BASE_NAME} * site libraries path: ${rubylibprefix}/${sitearch} * vendor path: ${rubylibprefix}/vendor_ruby * target OS: linux * compiler: gcc * with thread: pthread * with coroutine: amd64 * enable shared libs: yes * dynamic library ext: so * CFLAGS: ${optflags} ${debugflags} ${warnflags} * LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed \ -Wl,-z,pack-relative-relocs -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \ -Wl,--build-id=sha1 -fstack-protector-strong \ -rdynamic -Wl,-export-dynamic -Wl,--no-as-needed * DLDFLAGS: -Wl,-z,relro -Wl,--as-needed \ -Wl,-z,pack-relative-relocs -Wl,-z,now \ -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \ -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \ -Wl,--build-id=sha1 * optflags: -O3 -fno-fast-math * debugflags: -ggdb3 * warnflags: -Wall -Wextra -Wdeprecated-declarations \ -Wdiv-by-zero -Wduplicated-cond \ -Wimplicit-function-declaration -Wimplicit-int \ -Wpointer-arith -Wwrite-strings \ -Wold-style-definition -Wimplicit-fallthrough=0 \ -Wmissing-noreturn -Wno-cast-function-type \ -Wno-constant-logical-operand -Wno-long-long \ -Wno-missing-field-initializers \ -Wno-overlength-strings \ -Wno-packed-bitfield-compat \ -Wno-parentheses-equality -Wno-self-assign \ -Wno-tautological-compare -Wno-unused-parameter \ -Wno-unused-value -Wsuggest-attribute=format \ -Wsuggest-attribute=noreturn -Wunused-variable \ -Wmisleading-indentation -Wundef * strip command: strip -S -x * install doc: rdoc * YJIT support: yes * RJIT support: yes * man page type: doc --- ~~~ However, the option is not applied consistently, especially the `rubyhdrdir` stands out: ~~~ $ find . -name \*ruby3.3\* ./usr/lib64/ruby/ruby3.3 ./usr/lib64/ruby/site_ruby/ruby3.3 ./usr/lib64/ruby/vendor_ruby/ruby3.3 ./usr/lib64/ruby/gems/ruby3.3 ./usr/lib64/ruby/gems/ruby3.3/extensions/x86_64-linux/ruby3.3 ./usr/include/ruby-ruby3.3 ./usr/share/ri/ruby3.3 ~~~ The correct path should be IMHO `./usr/include/ruby3.3`. I can likely workaround it by `--with-rubyhdrdir`, but I think this should behave consistently. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115212] [Ruby master Bug#19983] Nested * seems incorrect
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #19983 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19983: Nested * seems incorrect https://bugs.ruby-lang.org/issues/19983 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ``` $ ruby -v -e 'def m(*); ->(*) { p(*) }; end; m(1).call(2)' ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] 1 ``` But I would expect `2`. Much like: ``` $ ruby -e 'def m(a); ->(a) { p(a) }; end; m(1).call(2)' ruby 3.3.0dev (2023-10-30T09:27:06Z master 14fa5e39d7) [x86_64-linux] 2 ``` i.e. the inner variable should win. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:115845] [Ruby master Bug#20078] StringIO cannot be moved between Ractors
by forthoney (Seong-Heon Jung) 11 Jan '24

11 Jan '24

Issue #20078 has been reported by forthoney (Seong-Heon Jung). ---------------------------------------- Bug #20078: StringIO cannot be moved between Ractors https://bugs.ruby-lang.org/issues/20078 * Author: forthoney (Seong-Heon Jung) * Status: Open * Priority: Normal * ruby -v: 3.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The following code will raise an unusual Ractor error. ``` ruby require 'stringio' r = Ractor.new { loop { Ractor.receive } } Ractor.shareable?(StringIO.new) #=> false r.send(StringIO.new) # passing it via copy works r.send(StringIO.new, move: true) # <internal:ractor>:587:in `send': can not move StringIO object. (Ractor::Error) ``` I'm not 100% sure but I believe that this probably not the intended behavior considering * The error raised is a generic `Ractor::Error` rather than something specific like Ractor::MovedError or Ractor::IsolationError * It can be copied * [No documentation](https://docs.ruby-lang.org/en/master/ractor_md.html) exists for this error * I have yet to seen this happen on any other class instance * Typo (can not -> cannot) -- https://bugs.ruby-lang.org/

3 6

[ruby-core:116061] [Ruby master Bug#20158] Ractor affects Coverage results
by janosch-x 11 Jan '24

11 Jan '24

Issue #20158 has been reported by janosch-x (Janosch Müller). ---------------------------------------- Bug #20158: Ractor affects Coverage results https://bugs.ruby-lang.org/issues/20158 * Author: janosch-x (Janosch Müller) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0preview1 (2023-05-12 master a1b01e7701) [arm64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I have a large rspec test suite. I found that if I call a Ractor, the Coverage results are strongly affected, i.e. almost all files appear to be uncovered. This happens even if I only ever call a Ractor before the library or rspec are required. Unfortunately, I was not able to build a simple repro yet. I assume it is a timing thing and only affects larger suites, or it only happens if there are multiple files, and maybe if the library lazily requires its sub-modules? However, I guess this should produce the same results when added to the spec_helper.rb of other large suites: ```ruby # Ractor.new { nil } # uncomment this to affect coverage results require 'coverage' Coverage.start # require library, set up rspec etc. RSpec.configuration.after(:suite) do # this number is greatly reduced and unstable when calling Ractor above p Coverage.result.values.sum { |arr| arr.sum(&:to_i) } end ``` I had this problem in [this library](https://github.com/jaynetics/character_set/). The problem affects simplecov users as well, as described [here](https://github.com/simplecov-ruby/simplecov/issues/1058). -- https://bugs.ruby-lang.org/

3 4

[ruby-core:116173] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by byroot (Jean Boussier) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by byroot (Jean Boussier). I would also like to try this again for 3.4, if we do it early, the potential remaining issue will have a chance to be noticed with the first preview release. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106186 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116172] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). Also given the efforts of @byroot in https://bugs.ruby-lang.org/issues/18576#note-21 and the offer from @matz in https://bugs.ruby-lang.org/issues/18576#note-19, I'd like to do exactly what matz said: > If you (or someone) estimate the compatibility issue is minimal, and want to experiment to see if it's true during pre-release, I'd say go. I estimate it to be minimal. We can know from the experiment if it's true or not, there are more than 11 months before 3.4, so plenty of time to discover any potential issue with it. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106185 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116170] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 11 Jan '24

11 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). @naruse Do you have evidence of (latest release and not ancient) gems or applications comparing `encoding.name` to `'ASCII-8BIT'`? I think it's so obviously a bad idea to compare the encoding name as a String, AFAIK there was never a valid reason to use it (over `enc == Encoding::BINARY`, which works since Ruby 1.9) and it's inefficient, brittle and unnecessary. FWIW https://github.com/search?q=%22name+%3D%3D+%27ASCII-8BIT%27%22&type=code&p=1 shows very few matches and it's mostly copies of old VCR code. The chance of that code running on Ruby 3.4+ seems almost nonexistent, there would likely be many more serious compatibility issues with such old code (e.g. kwargs changes). And fixing it is really easy. @matz Can we experiment for 3.4? If we have pushback based on actual code then let's go more conservative, but otherwise I think we should do the clean fix here. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106183 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115736] [Ruby master Bug#20064] Inconsistent behavior between array splat *nil and hash splat **nil
by zeke (Zeke Gabrielse) 11 Jan '24

11 Jan '24

Issue #20064 has been reported by zeke (Zeke Gabrielse). ---------------------------------------- Bug #20064: Inconsistent behavior between array splat *nil and hash splat **nil https://bugs.ruby-lang.org/issues/20064 * Author: zeke (Zeke Gabrielse) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This has been discussed in #8507 and #9291 but both were closed because they lacked a clear use case. I think the following code should work, showing a clear use case: ```ruby invitation = if params.key?(:inviter_id) { invitation_attributes: params.slice(:inviter_id) } end User.create( email: 'john.doe(a)ruby.example', first_name: 'John', first_name: 'Doe', **invitation, ) ``` Per the previous discussions, this is because `*` uses explicit conversion to array (`to_a`, not `to_ary`), while `**` uses implicit conversion to hash (`to_hash`, not `to_h`). I find it confusing that you can splat nil into an array, but not nil into a hash. It would make sense for `**` to use explicit conversion. -- https://bugs.ruby-lang.org/

4 4