June 2024 - 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: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: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: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

[ruby-core:117037] [Ruby master Bug#20322] rb_enc_interned_str_cstr doesn't accept null pointer for encoding
by thomasmarshall (Thomas Marshall) 15 Jul '24

15 Jul '24

Issue #20322 has been reported by thomasmarshall (Thomas Marshall). ---------------------------------------- Bug #20322: rb_enc_interned_str_cstr doesn't accept null pointer for encoding https://bugs.ruby-lang.org/issues/20322 * Author: thomasmarshall (Thomas Marshall) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The [header documentation](https://github.com/ruby/ruby/blob/93556d46203545bc2364b1c0dd… for `rb_enc_interned_str_cstr` notes: > `enc` can be a null pointer. When [adding support for this function to TruffleRuby](https://github.com/oracle/truffleruby/pull/3427) we noticed that the behaviour did not match that documentation. I think this did work previously, but it currently causes a segmentation fault when trying to [autoload the encoding](https://github.com/ruby/ruby/blob/93556d46203545bc2364b1c0dd1281b… because it calls `rb_enc_mbmaxlen` which [expects a non-null encoding](https://github.com/ruby/ruby/blob/93556d46203545bc2364b1c0dd1281b…. I'm not sure how important this behaviour is, whether extensions ever actually call this with a null pointer, or if the documentation is instead just incorrect. I think it's a straightforward fix to make the behaviour match the documentation, so I would like to open a PR, but also happy to just remove the note if that is preferable. -- https://bugs.ruby-lang.org/

4 4