- ruby-core - ml.ruby-lang.org

[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

[ruby-core:118620] [Ruby master Bug#20638] Threads not collected by GC under RUBY_MN_THREADS=1
by jhawthorn (John Hawthorn) 16 Jul '24

16 Jul '24

Issue #20638 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #20638: Threads not collected by GC under RUBY_MN_THREADS=1 https://bugs.ruby-lang.org/issues/20638 * Author: jhawthorn (John Hawthorn) * 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 ---------------------------------------- When running with `RUBY_MN_THREADS=1` I noticed increased memory usage when creating many threads. It seems like Threads aren't able to be collected when run concurrently. ``` $ ruby -e '500.times { 50.times.map { Thread.new{} }.map(&:join) }; sleep 1; GC.start; p ObjectSpace.each_object(Thread).count' 1 $ RUBY_MN_THREADS=1 ruby -e '500.times { 50.times.map { Thread.new{} }.map(&:join) }; sleep 1; GC.start; p ObjectSpace.each_object(Thread).count' 24501 ``` (Note that 24500 is 500 * 49. It seems like each time we make the 50 concurrent threads 49 of them leak) I tested both on macos and linux and this occurs both on Ruby 3.3 and head. No combination of sleeping or GC seems to clear them. According to a heap dump these are being held in memory by the VM root. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118347] [Ruby master Bug#20587] dir.c calls blocking system calls while holding the GVL
by ivoanjo (Ivo Anjo) 16 Jul '24

16 Jul '24

Issue #20587 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #20587: dir.c calls blocking system calls while holding the GVL https://bugs.ruby-lang.org/issues/20587 * Author: ivoanjo (Ivo Anjo) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hey! I work for Datadog on the Ruby profiler part of the [`datadog` (previously `ddtrace`)](https://github.com/datadog/dd-trace-rb) gem. While I was investigating https://bugs.ruby-lang.org/issues/20586, I spotted that there's a number of cases where, in `dir.c`, blocking system calls are being made (e.g. `readdir()`, `opendir()`, etc) without releasing the GVL. This means that if they block for a long time (as happens in the gcsfuse example in https://bugs.ruby-lang.org/issues/20586 ), the Ruby VM will just be blocked and not make any progress. The combination of not releasing the GVL + slow system calls actually makes the issue in https://bugs.ruby-lang.org/issues/20586 more likely to happen with the Datadog profiler, although even if the code releases the GVL the underlying issue could still happen, and this is why I decided to file this bug separately. -- https://bugs.ruby-lang.org/

2 6

[ruby-core:118611] [Ruby master Misc#20636] typo in `configure` script
by gsteemso (Gordon Steemson) 16 Jul '24

16 Jul '24

Issue #20636 has been reported by gsteemso (Gordon Steemson). ---------------------------------------- Misc #20636: typo in `configure` script https://bugs.ruby-lang.org/issues/20636 * Author: gsteemso (Gordon Steemson) * Status: Open ---------------------------------------- At lines 20276-20277, the `configure` script misspells "deprecated" as "depreacted". This appears to be purely cosmetic, but is still mildly astonishing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118609] [Ruby master Bug#14582] Unable to use `method__entry` and `method_return` tracing probes since 2.5
by vo.x (Vit Ondruch) 15 Jul '24

15 Jul '24

Issue #14582 has been updated by vo.x (Vit Ondruch). In Fedora / RHEL, we would still be interested in re-enabling this functionality. @jaruga are there by a chance upstream SystemTap tests? I think that something similar to `annocheck` test coverage would be cool. ---------------------------------------- Bug #14582: Unable to use `method__entry` and `method_return` tracing probes since 2.5 https://bugs.ruby-lang.org/issues/14582#change-109139 * Author: guilhermereiscampos (Guilherme Reis Campos) * Status: Open * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Hi, I am trying to use dtrace/systemtap probes and not being able to use it after the 2.5. The 2.4 version works fine. I was hoping this was fixed on 2.6-preview, but apparently not (just downloaded dev and tested). I tried on OSX using dtrace and also on ubuntu (vagrant). ``` # test.rb class Foo def bar 100.times { "Bar" } end end foo = Foo.new foo.bar # test.stp probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__entry") # you will need to change this to your ruby path of your version. { printf("%s => %s.%s in %s:%d\n", thread_indent(1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } probe process("/home/vagrant/.rbenv/versions/2.4.0/bin/ruby").mark("method__return") { printf("%s <= %s.%s in %s:%d\n", thread_indent(-1), kernel_string($arg1),kernel_string($arg2),kernel_string($arg3),$arg4); } ``` dtrace was something similar to it. I was expecting to see this output: ``` # lots of calls # .... # then: 4090 ruby(9667): <= Gem::Specification.unresolved_deps in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/specification.rb:1298 4095 ruby(9667): => MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:197 4100 ruby(9667): => MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:247 4104 ruby(9667): <= MonitorMixin.mon_check_owner in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:251 4109 ruby(9667): <= MonitorMixin.mon_exit in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/monitor.rb:204 4283 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 4303 ruby(9667): <= Kernel.require in /home/vagrant/.rbenv/versions/2.4.0/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55 0 ruby(9667): => Foo.bar in test.rb:3 16 ruby(9667): <= Foo.bar in test.rb:5 ``` (The output above is 2.4) my ruby (all versions that I tested) was install with rb-env: ``` RUBY_CONFIGURE_OPTS='--enable-dtrace --disable-install-doc' rbenv install 2.5.0 ``` I am happy to provide details if required. I'd also be happy to fix it if I have guidance. Thanks, -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118132] [Ruby master Bug#20517] `Ripper.tokenize('"\\M-あ"')` separates encoding valid string to encoding invalid string.
by tompng (tomoya ishida) 15 Jul '24

15 Jul '24

Issue #20517 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20517: `Ripper.tokenize('"\\M-あ"')` separates encoding valid string to encoding invalid string. https://bugs.ruby-lang.org/issues/20517 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-04-11T08:57:52Z master e7f8db9079) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ~~~ruby Ripper.tokenize '"\\M-あ"' => ["\"", "\\M-\xE3", "\x81", "\x82", "\""] ~~~ I expect all tokens to be valid_encoding if the source string is valid_encoding. Similar to https://bugs.ruby-lang.org/issues/20030 -- https://bugs.ruby-lang.org/

4 3