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

[ruby-core:114792] [Ruby master Bug#19887] RUBYOPT doesn't work unless starting with `-`
by nobu (Nobuyoshi Nakada) 20 Jul '24

20 Jul '24

Issue #19887 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19887: RUBYOPT doesn't work unless starting with `-` https://bugs.ruby-lang.org/issues/19887 * Author: nobu (Nobuyoshi Nakada) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- It was working till 1.8. ```sh-session $ for ruby in ruby{1.{8..9},2.{0..7},3.{0..3}}; do RUBYOPT=w $ruby -e 'puts "'$ruby': #{$VERBOSE}"'; done ruby1.8: true ruby1.9: false ruby2.0: false ruby2.1: false ruby2.2: false ruby2.3: false ruby2.4: false ruby2.5: false ruby2.6: false ruby2.7: false ruby3.0: false ruby3.1: false ruby3.2: false ruby3.3: false ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:115728] [Ruby master Bug#20062] Numbered parameters are broken in Ruby 3.3-dev
by osyo (manga osyo) 20 Jul '24

20 Jul '24

Issue #20062 has been reported by osyo (manga osyo). ---------------------------------------- Bug #20062: Numbered parameters are broken in Ruby 3.3-dev https://bugs.ruby-lang.org/issues/20062 * Author: osyo (manga osyo) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-12-13T13:16:11Z master f390c51b15) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Define Numbered parameters and a method in one block and then reference Numbered parameters in another block, you will get a SyntaxError in Ruby 3.3. This is not a problem in Ruby 3.2. ```ruby 'a'.tap do p _1 def f1; end end 'a'.tap do p _1 end __END__ output: Ruby 3.2.2 => "a" "a" Ruby 3.3.0dev(2023-12-13T13:16:11Z master f390c51b15) => /path/to/test.rb: /path/to/test.rb:8: numbered parameter is already used in (SyntaxError) /path/to/test.rb:2: outer block here ``` I noticed this while checking the operation of https://bugs.ruby-lang.org/issues/18966. I haven't checked, but https://bugs.ruby-lang.org/issues/19619 may be related. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:114258] [Ruby master Bug#19781] Stack consistency error with tailcall and YJIT enabled
by k0kubun (Takashi Kokubun) 20 Jul '24

20 Jul '24

Issue #19781 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19781: Stack consistency error with tailcall and YJIT enabled https://bugs.ruby-lang.org/issues/19781 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal * Assignee: yjit * Backport: 3.0: DONTNEED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```rb src = <<-EOS def apply_one_and_two(&block) [1, p(1)] end def add_one_and_two apply_one_and_two(&:+) end EOS RubyVM::InstructionSequence.new( "proc {|_|_.class_eval {#{src}}}", __FILE__, __FILE__, 1, tailcall_optimization: true, trace_instruction: false, ).eval[self.singleton_class] def entry add_one_and_two end entry ``` This script causes "Stack consistency error" with `ruby --yjit-call-threshold=1` on any YJIT-enabled build (3.1, 3.2, and master). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117763] [Ruby master Bug#20468] Segfault on safe navigation in for target
by kddnewton (Kevin Newton) 20 Jul '24

20 Jul '24

Issue #20468 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20468: Segfault on safe navigation in for target https://bugs.ruby-lang.org/issues/20468 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby for foo&.bar in []; end ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:118373] [Ruby master Bug#20592] Interrupting Addrinfo causes Segmentation fault on alpine
by haukot (Dmitry Davydov) 20 Jul '24

20 Jul '24

Issue #20592 has been reported by haukot (Dmitry Davydov). ---------------------------------------- Bug #20592: Interrupting Addrinfo causes Segmentation fault on alpine https://bugs.ruby-lang.org/issues/20592 * Author: haukot (Dmitry Davydov) * Status: Open * ruby -v: ruby 3.4.0preview1 (2024-05-16 master 9d69619623) [x86_64-linux-musl] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- On Alpine 3.20 got a segfault when interrupting Addrinfo request which would resolve with error. Same on ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux-musl] Tried on docker image alpine3.20 and ruby:3.4.0-preview1-alpine. ```ruby # test.rb require 'socket' require 'timeout' begin Addrinfo.ip("1234.example.com") rescue StandardError => e puts e end sleep 10 # wait getaddrinfo to resolve and fail ``` ``` /app # ruby test.rb execution expired [BUG] Segmentation fault at 0x0000000000000028 ruby 3.4.0preview1 (2024-05-16 master 9d69619623) [x86_64-linux-musl] -- Machine register context ------------------------------------------------ RIP: 0x00007fefe4cd4886 RBP: 0x0000000000000001 RSP: 0x00007fefc95d3a10 RAX: 0x0000000000000001 RBX: 0x00007fefc94212e0 RCX: 0x00007fefc95d0b70 RDX: 0x0000000000000010 RDI: 0x0000000000000000 RSI: 0x00007fefc95d08f0 R8: 0x0000000000000000 R9: 0x0000000000000000 R10: 0x0000000000000000 R11: 0x0000000000000217 R12: 0x00007fefc9421340 R13: 0x00007fff5a0ec750 R14: 0x00007fefe4649b10 R15: 0x00007fefc95d3b38 EFL: 0x0000000000010202 -- Other runtime information ----------------------------------------------- ``` gdb logs ``` /app # gdb -q --args ruby test.rb (gdb) run Starting program: /usr/local/bin/ruby test.rb warning: Error disabling address space randomization: Operation not permitted [New LWP 36] [New LWP 37] [New LWP 38] execution expired Thread 4 "ruby" received signal SIGSEGV, Segmentation fault. [Switching to LWP 38] 0x00007f0a2c33b886 in freeaddrinfo (p=0x0) at src/network/freeaddrinfo.c:10 warning: 10 src/network/freeaddrinfo.c: No such file or directory (gdb) bt #0 0x00007f0a2c33b886 in freeaddrinfo (p=0x0) at src/network/freeaddrinfo.c:10 #1 0x00007f0a10c1e940 in do_getaddrinfo (ptr=0x7f0a10f61200) at raddrinfo.c:426 #2 0x00007f0a2c35c349 in start (p=0x7f0a10afaa88) at src/thread/pthread_create.c:207 #3 0x00007f0a2c35e95f in __clone () at src/thread/x86_64/clone.s:22 Backtrace stopped: frame did not save the PC (gdb) info args p = 0x0 ``` There are no errors if Addrinfo resolves with data ``` Timeout.timeout(0.01) { Addrinfo.ip("ruby-lang.org") } # finishes correctly ``` The problem is that freeaddrinfo on alpine does not accept a NULL pointer (ref https://git.musl-libc.org/cgit/musl/tree/src/network/freeaddrinfo.c) ---Files-------------------------------- segfault_gdb (1.56 KB) segfault (14.1 KB) -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118279] [Ruby master Bug#20573] Warning.warn shouldn't be called for disabled warnings
by tenderlovemaking (Aaron Patterson) 20 Jul '24

20 Jul '24

Issue #20573 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #20573: Warning.warn shouldn't be called for disabled warnings https://bugs.ruby-lang.org/issues/20573 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Currently `Warning.warn` will be called for all warnings, even if that particular category is disabled. For example ```ruby module Warning def warn(message, category:) p message => category end end def get_var $= end p Warning[:deprecated] get_var ``` I think that internally we should _not_ call `Warning.warn` unless the category is enabled. I've sent a PR here: https://github.com/ruby/ruby/pull/10960 -- https://bugs.ruby-lang.org/

5 9

[ruby-core:118642] [Ruby master Bug#20643] Ruby 3.2 behavior change for protected and private methods when yield self
by tatethurston (Tate Thurston) 20 Jul '24

20 Jul '24

Issue #20643 has been reported by tatethurston (Tate Thurston). ---------------------------------------- Bug #20643: Ruby 3.2 behavior change for protected and private methods when yield self https://bugs.ruby-lang.org/issues/20643 * Author: tatethurston (Tate Thurston) * Status: Open * ruby -v: ruby 3.2.4 (2024-04-23 revision af471c0e01) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I noticed the following behavior change when updating my application from Ruby 3.1 to Ruby 3.2. Using the following code: ``` ruby class Foo def try yield self end private def bar puts "private method bar called" end end Foo.new.try(&:bar) ``` Under 3.1 (ruby 3.1.6p260 (2024-05-29 revision a777087be6) [arm64-darwin23]) ``` private method bar called => nil ``` Under Ruby 3.2 (ruby 3.2.4 (2024-04-23 revision af471c0e01) [arm64-darwin23]) ``` (irb):4:in `try': private method `bar' called for #<Foo:0x000000010770a578> (NoMethodError) from (irb):14:in `<main>' from /Users/tatthurs/.asdf/installs/ruby/3.2.4/lib/ruby/gems/3.2.0/gems/irb-1.6.2/exe/irb:11:in `<top (required)>' from /Users/tatthurs/.asdf/installs/ruby/3.2.4/bin/irb:25:in `load' from /Users/tatthurs/.asdf/installs/ruby/3.2.4/bin/irb:25:in `<main>' irb(main):015:0> ``` Is this change expected? I could not find a note in the changelog. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:118639] [Ruby master Bug#20642] YJIT prevents hardening
by vo.x (Vit Ondruch) 19 Jul '24

19 Jul '24

Issue #20642 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20642: YJIT prevents hardening https://bugs.ruby-lang.org/issues/20642 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Working on #20621, it can be seen that annocheck reports: ~~~ Hardened: libruby.so.3.4.0: skip: cf-protection test because mixed Rust and C code - control flow protection is needed but not yet supported by Rust ~~~ To me it is unfair that Ruby users should make a choice between YJIT and hardening. I don't think that Ruby is going to give up YJIT, but maybe Ruby community could put some pressure on Rust? https://github.com/rust-lang/rust/issues/93754 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:118529] [Ruby master Bug#20623] Unexpected behavior of blocks in LazyEnumerator#map
by esad (Esad Hajdarevic) 19 Jul '24

19 Jul '24

Issue #20623 has been reported by esad (Esad Hajdarevic). ---------------------------------------- Bug #20623: Unexpected behavior of blocks in LazyEnumerator#map https://bugs.ruby-lang.org/issues/20623 * Author: esad (Esad Hajdarevic) * Status: Open * ruby -v: 3.3.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've stumbled upon unexpected behaviour of lazy enumerators. My example: ``` [1].cycle.lazy.zip([2].cycle.lazy).map do |x| puts x.inspect end.take(5).force puts "---" [1].cycle.lazy.zip([2].cycle.lazy).take(5).force.map do |x| puts x.inspect end ``` The outputs (and variable assignment inside the block) differs ``` 1 1 1 1 1 --- [1, 2] [1, 2] [1, 2] [1, 2] [1, 2] ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118631] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by Dan0042 (Daniel DeLorme) 18 Jul '24

18 Jul '24

Issue #6648 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-23: > If you really want to "launch subprocess Ruby instances with the same settings", we might want to consider a more dedicated API for it, instead of parsing the command line to a string array and passing it to `Kernel#exec`. A "more dedicated API" sounds not so good to me. It's more complex and also less versatile. One of the use cases was certainly to (re-)execute the current ruby, but in #note-10 I also mentioned executing a different version of ruby, like `exec("ruby-3.0", *filter_for_ruby30(RbConfig.ruby_args), script)`. This would not be possible with a dedicated API. Not to mention other potential uses like `RbConfig.ruby_args.include?('-v')` to know if the version number was printed. shyouhei (Shyouhei Urabe) wrote in #note-29: > Please note that I'm not necessarily against a way to call the current ruby executable. I just say doing so using exec is a bad idea, because exec is not designed for that purpose. Maybe that's true on Windows, but on Unix `exec` is very much the normal and blessed way to re-execute the current program. I understand there are challenges on Windows, but they are inherent to the existing system/spawn methods, and will not change regardless of adding `RbConfig.ruby_args`. I don't think it's a good idea to hobble Unix just because Windows has some design flaws. nobu (Nobuyoshi Nakada) wrote in #note-33: > `Kernel#exec` is not implemented on Windows. Then maybe `RbConfig.ruby_args` should not be implemented on Windows if it's such a problem? (Though I don't see why.) ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109158 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * Scanning globals and hoping they have not been tweaked to new settings * Using external wrappers to launch Ruby * ??? Inability to get the full set of command-line flags, including flags passed to the VM itself (and probably VM-specific) makes it impossible to launch subprocess Ruby instances with the same settings. A real world example of this is "((%bundle exec%))" when called with a command line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S bundle exec%)). None of these flags can propagate to the subprocess, so odd behaviors result. The only option is to put the flags into an env var (((|JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for accessing comand-line options, but I do not know if it includes VM-level flags as well as standard Ruby flags. I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace is intended to be general-purpose for VM-level features, it would be a good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps with $0 def script_args; end # returns args passed to the script...though this overlaps with ARGV, but that is perhaps warranted since ARGV can be modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/

1 0