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

[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

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

15 Jul '24

Issue #20030 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20030: `Ripper.tokenize('"\\C-あ"')` separates encoding valid string to encoding invalid string. https://bugs.ruby-lang.org/issues/20030 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-11-30T16:23:25Z master d048bae96b) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ~~~ruby Ripper.tokenize '"\\C-あ"' # or Ripper.tokenize "\"\\C-\u3042\"" # => ["\"", "\x81", "\x82", "\""] ~~~ I expect all tokens to be valid_encoding if the source string is valid_encoding. This is causing IRB crash when typing `"\C-あ"`. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:117992] [Ruby master Bug#20505] Reassigning the block argument in method body keeps old block when calling super with implicit arguments
by Earlopain (A S) 15 Jul '24

15 Jul '24

Issue #20505 has been reported by Earlopain (A S). ---------------------------------------- Bug #20505: Reassigning the block argument in method body keeps old block when calling super with implicit arguments https://bugs.ruby-lang.org/issues/20505 * Author: Earlopain (A S) * Status: Open * ruby -v: 3.3.1 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- You can call super without arguments and parenthesis to pass along all the enclosing method arguments to the parent method. You can modify positional and keyword arguments before the call to super, and the parent method will recieve these modified values. With the block arg however that isn't the case: ```rb class A def positional_arg(a) puts a end def block_arg(&block) yield end end class B < A def positional_arg(a = nil) a = 'b' super end def block_arg(&block) block = proc { puts 'b' } super end end B.new.positional_arg('a') B.new.positional_arg B.new.block_arg { puts 'a' } B.new.block_arg ``` I would expect this snippet to print `b` four times. The actual output is `b` `b` `a` and `LocalJumpError`. To get the desired output I must pass the block along explicitly with `super(&block)`. I hope my example explains the issue good enough. I have looked through issues here and searched for documentation and haven't found any mention of this behaviour. Sorry if I missed something somewhere. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:117200] [Ruby master Bug#20342] Top level `public`, `private` and `ruby2_keywords` do not work in wrapped load
by nobu (Nobuyoshi Nakada) 15 Jul '24

15 Jul '24

Issue #20342 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #20342: Top level `public`, `private` and `ruby2_keywords` do not work in wrapped load https://bugs.ruby-lang.org/issues/20342 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED ---------------------------------------- With this file: ```ruby # load.rb public def f = :ok ``` It is OK when `require`d. ```sh-session $ ruby -r ./load.rb -e 'p f' :ok ``` Simple `load` is OK too. ```sh-session $ ruby -e 'load ARGV[0]; p f' load.rb :ok ``` Wrapped `load` fails. ```sh-session $ ruby -e 'load ARGV[0], true' load.rb load.rb:1:in 'public': undefined method 'f' for class 'Object' (NameError) public def f = :ok ^^^^^^ from load.rb:1:in '<top (required)>' from -e:1:in 'Kernel#load' from -e:1:in '<main>' ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:117697] [Ruby master Bug#20453] Pointer being freed was not allocated in Regexp timeout
by dodecadaniel (Daniel Colson) 15 Jul '24

15 Jul '24

Issue #20453 has been reported by dodecadaniel (Daniel Colson). ---------------------------------------- Bug #20453: Pointer being freed was not allocated in Regexp timeout https://bugs.ruby-lang.org/issues/20453 * Author: dodecadaniel (Daniel Colson) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- https://bugs.ruby-lang.org/issues/20228 frees `stk_base` to avoid a memory leak, but `stk_base` is sometimes stack allocated ([see `xalloca`](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1177-L1181)). So the free only works if the regex stack grows enough that it needs to double ([see `xmalloc` and `xrealloc` in `stack_double`](https://github.com/ruby/ruby/blob/dde99215f2bc60c22a00fc941ff7f714f011e920/regexec.c#L1210-L1249). Reproduction: ```ruby Regexp.timeout = 0.001 /^(a*)x$/ =~ "a" * 1000000 + "x"' ``` I'll open a PR shortly. https://bugs.ruby-lang.org/issues/20228 was backported to 3.3.1, so this bug affects that version as well. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118299] [Ruby master Feature#20576] Add MatchData#bytebegin and MatchData#byteend
by shugo (Shugo Maeda) 15 Jul '24

15 Jul '24

Issue #20576 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #20576: Add MatchData#bytebegin and MatchData#byteend https://bugs.ruby-lang.org/issues/20576 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 3.4 ---------------------------------------- I'd like to propose MatchData#bytebegin and MatchData#byteend. These methods are similar to MatchData#begin and MatchData#end, but returns offsets in bytes instead of codepoints. Pull request: https://github.com/ruby/ruby/pull/10973 One of the use cases is scanning strings: https://github.com/ruby/net-imap/pull/286/files MatchData#byteend is faster than MatchData#byteoffset because there is no need to allocate an Array. Here's a benchmark result: ``` voyager:ruby$ cat b.rb require "benchmark" require "strscan" text = "あ" * 100000 Benchmark.bmbm do |b| b.report("byteoffset(0)[1]") do pos = 0 while text.byteindex(/\G./, pos) pos = $~.byteoffset(0)[1] end end b.report("byteend(0)") do pos = 0 while text.byteindex(/\G./, pos) pos = $~.byteend(0) end end end voyager:ruby$ ./tool/runruby.rb b.rb Rehearsal ---------------------------------------------------- byteoffset(0)[1] 0.020558 0.000393 0.020951 ( 0.020963) byteend(0) 0.018149 0.000000 0.018149 ( 0.018151) ------------------------------------------- total: 0.039100sec user system total real byteoffset(0)[1] 0.020821 0.000000 0.020821 ( 0.020822) byteend(0) 0.017455 0.000000 0.017455 ( 0.017455) ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:118600] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
by nobu (Nobuyoshi Nakada) 15 Jul '24

15 Jul '24

Issue #6648 has been updated by nobu (Nobuyoshi Nakada). Eregon (Benoit Daloze) wrote in #note-31: > mame (Yusuke Endoh) wrote in #note-23: > > > [...] instead of parsing the command line to a string array and passing it to `Kernel#exec`. > > Don't we use `execve()` (which takes `char**`) as well on Windows for `Kernel#exec`? > It does seem to exist: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/execve-we… `Kernel#exec` is not implemented on Windows. > Did you mean `Kernel#spawn`/`Kernel#system` maybe? Argument passing is same for them. Eregon (Benoit Daloze) wrote in #note-32: > And from a quick look there is also [`_spawnv`](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv?view=msvc-170) which does take a `char**`, maybe we could use that on Windows? `_spawnv` is not an API but a just wrapper of `CreateProcess` as well as `rb_w32_uspawn`, but lacks some arguments. We use `rb_w32_uspawn` and `rb_w32_uspawn_flags` to support redirection and a few flags. Our functions are designed based on `_spawnv` in msvcrt, so the security concern is similar. The argument handling would work fine for many commands using msvcrt or `ruby`, but not all. 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`. This means a restricted method to invoke only `ruby` not to run other arbitrary commands, which can interpret the arguments wrongly, by "a more dedicated API", I think. ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109127 * 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:116950] [Ruby master Bug#20304] Memory leak when setting Encoding.default_internal
by MaxLap (Maxime Lapointe) 15 Jul '24

15 Jul '24

Issue #20304 has been reported by MaxLap (Maxime Lapointe). ---------------------------------------- Bug #20304: Memory leak when setting Encoding.default_internal https://bugs.ruby-lang.org/issues/20304 * Author: MaxLap (Maxime Lapointe) * Status: Open * ruby -v: 3.3.0 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Problem is present in Ruby 3.2.2, 3.2.3, 3.3.0. Didn't check before. Put this in a file: ``` 10.times do 100000.times do Encoding.default_internal = nil end puts `ps -o rss= -p #{$$}`.to_i end ``` Result: ``` $ ruby local.rb 27044 30212 33116 36284 39452 42620 45788 48956 51860 55028 ``` -- https://bugs.ruby-lang.org/

4 4