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

[ruby-core:112051] [Ruby master Bug#19380] IO.read doesn't validate the offset argument

by andrykonchin (Andrew Konchin)

Issue #19380 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #19380: IO.read doesn't validate the offset argument https://bugs.ruby-lang.org/issues/19380 * Author: andrykonchin (Andrew Konchin) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I've noticed that when passed negative `offset` argument `IO.read` raises a bit confusing error: ```ruby IO.read("read-test.txt", 1, -1) # (irb):55:in `read': Invalid argument @ rb_io_seek - read-test.txt (Errno::EINVAL) ``` But error for invalid `length` argument is much more helpful: ```ruby IO.read("read-test.txt", -1) # (irb):56:in `read': negative length -1 given (ArgumentError) ``` I would expect a similar ArgumentError exception to be raised for invalid `offset` argument instead of `Invalid argument @ rb_io_seek - read-test.txt (Errno::EINVAL)` -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:112052] [Ruby master Bug#19381] SEGV - ivars, both Ubuntu & Windows

by MSP-Greg (Greg L)

Issue #19381 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #19381: SEGV - ivars, both Ubuntu & Windows https://bugs.ruby-lang.org/issues/19381 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-01-26T07:31:08Z master 6422fef90c) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I've used code similar to the below for a long time. When max is set to 50, it runs. When max is set to 51, it SEGV faults. Rubies tested: ruby 3.3.0dev (2023-01-26T07:31:08Z master 6422fef90c) [x86_64-linux] ruby 3.3.0dev (2023-01-26T07:31:08Z master 6422fef90c) [x64-mingw-ucrt] ruby 3.3.0dev (2023-01-26T07:31:08Z master 6422fef90c) [x64-mswin64_140] I suspect it involves the changes in https://github.com/ruby/ruby/pull/7183 'Limit maximum number of IVs on a shape' ```ruby module Test class << self def run max = 51 (1..max).each do |v| instance_variable_set("@iv#{v}".to_sym, nil) end end end end Test.run puts Test.instance_variables ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

4
4
0 0

[ruby-core:111604] [Ruby master Misc#19304] Kernel vs Object documentation

by zverok (Victor Shepelev)

Issue #19304 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #19304: Kernel vs Object documentation https://bugs.ruby-lang.org/issues/19304 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- The restating of the problems raised in #19300, from scratch. I believe it is rather a topic of **community significance** and would be happy if it is possible to **discuss on dev-meeting**, even if the outcome would probably "let's change RDoc in this or that way". So, the problem statement: 1. `Kernel` module defines two "types" of methods: private ones, that pretend to be global (like `puts`), but actually available from inside every object; and public ones (like `#class` or `#frozen?`) that are present in every object including `Kernel`. 2. Since the beginning of times, docs provided an illusion that the second type of the methods belongs to `Object` class, which is, in fact, devoid of its own definitions, just includes `Kernel`. This was handled by special RDoc hack (which, basically, forcefully [reattached definition](https://github.com/ruby/rdoc/blob/017bb9fa496ee0e0959facba694a0… of public methods if they are defined in `Kernel`, to `Object`) 3. The RDoc hack was working in C code only, so after introduction of `kernel.rb` the illusion started to crumble: methods like `#tap`, `#then`, `#class` [are now documented](https://docs.ruby-lang.org/en/3.2/Kernel.html) as belonging to `Kernel` (breaking the tradition of public methods being documented in `Object`) 4. This is all inconsistent and confusing, and I believe, adds to friction both for newcomers and curious investigators of the language! Additionally, I believe: 1. That the distinction of "two kinds of methods" is useful (saying from a practical experience with explaining Ruby while mentoring, writing articles, and discussing with colleagues) 2. But, considering everything, I agree with what @Eregon and @nobu say in #19300: pretending that methods belong not to the module they really belong to is not the optimal way to document things! So, the options I see (save for "do nothing and let things sort themselves somehow"): 1. Change Ruby's implementation so public methods would really belong to `Object`. Actually, I don't believe anybody would agree to experiment on this scale, so just listing it here for completeness. 2. Just remove the RDoc hack; all methods would belong to `Kernel`, and maybe some introductory free-form text will instruct that they are different. **Pro:** Easy to do. **Contra:** The `Kernel` docs would be super-confusing. 3. Continue to maintain the hack in RDoc and extend it to `kernel.rb` (so methods like `#clone` and `#frozen?` would be still in `Object`). **Pro:** Relatively easy to do, will maintain structure many people used to. **Contra:** This is still a lie, methods belong to `Kernel`, not `Object`. 4. Adjust RDoc to a) be able to separately list **public** and **private** methods in two different lists, and add intro for `Kernel` explaining how to treat those. **Pro:** Probably the best correspondence to reality? **Contra:** Not sure how easy it is to change RDoc this way; and other renderers (like ruby-doc.com and rubyapi.org) would need to adjust themselves. So far, (4) looks the most reasonable (if (1) is 100% impossible, that is!) -- https://bugs.ruby-lang.org/

1 year, 3 months

6
7
0 0

[ruby-core:111842] [Ruby master Feature#19347] Add Dir.fchdir

by jeremyevans0 (Jeremy Evans)

Issue #19347 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #19347: Add Dir.fchdir https://bugs.ruby-lang.org/issues/19347 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- Recently, I was working on a program that passes file descriptors over UNIX sockets (using `send_io`/`recv_io`). For file/socket/device descriptors, this works fine using `File#reopen`. However, I found that while Ruby supports `Dir#fileno` to return a directory file descriptor, it cannot use that file descriptor when changing directories. I worked around this in my program by writing the directory path over the UNIX socket, but this results in a TOCTOU vulnerability in certain cases. Passing the directory file descriptor would be simpler and avoid the vulnerability. I've submitted a pull request to implement this method: https://github.com/ruby/ruby/pull/7135 -- https://bugs.ruby-lang.org/

1 year, 3 months

4
8
0 0

[ruby-core:112097] [Ruby master Feature#19388] Deprecate SecurityError

by jeremyevans0 (Jeremy Evans)

Issue #19388 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #19388: Deprecate SecurityError https://bugs.ruby-lang.org/issues/19388 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I think we should deprecate `SecurityError` in Ruby 3.3 and remove it in Ruby 3.4. I think we probably should have deprecated `SecurityError` when `$SAFE` was deprecated, but better late than never. I've submitted a pull request to deprecate it: https://github.com/ruby/ruby/pull/7193 -- https://bugs.ruby-lang.org/

1 year, 3 months

3
2
0 0

[ruby-core:111501] [Ruby master Bug#19283] Regex error on ruby 3.2

by Sho (Shohei Nakano)

Issue #19283 has been reported by Sho (Shohei Nakano). ---------------------------------------- Bug #19283: Regex error on ruby 3.2 https://bugs.ruby-lang.org/issues/19283 * Author: Sho (Shohei Nakano) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is an regex error pattern on ruby 3.2.0. This pattern is success on ruby 3.1.3. Is this a bug? Or, is ruby 3.2.0 correct? - ruby 3.2.0 ``` # ruby -v ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') nil ``` - ruby 3.1.3 ``` # ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

1
2
0 0

[ruby-core:111461] [Ruby master Feature#19272] Hash#merge: smarter protocol depending on passed block arity

by zverok (Victor Shepelev)

Issue #19272 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19272: Hash#merge: smarter protocol depending on passed block arity https://bugs.ruby-lang.org/issues/19272 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Usage of `Hash#merge` with a "conflict resolution block" is almost always clumsy: due to the fact that the block accepts `|key, old_val, new_val|` arguments, and many trivial usages just somehow sum up old and new keys, the thing that should be "intuitively trivial" becomes longer than it should be: ```ruby # I just want a sum! {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |_, o, n| o + n } # I just want a group! {words: %w[I just]}.merge(words: %w[want a group]) { |_, o, n| [*o, *n] } # I just want to unify flags! {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE) { |_, o, n| o | n } # ...or, vice versa: {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE) { |_, o, n| o & n } ``` It is especially noticeable in the last two examples, but the _usual_ problem is there are too many "unnecessary" punctuation, where the essential might be lost. There are proposals like #19148, which struggle to define _another_ method (what would be the name? isn't it just merging?) But I've been thinking, can't the implementation be chosen based on the arity of the passed block?.. Prototype: ```ruby class Hash alias old_merge merge def merge(other, &block) return old_merge(other) unless block if block.arity.abs != 2 old_merge(other, &block) else old_merge(other) { |_, o, n| block.call(o, n) } end end end {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5, &:+) #=> {:apples=>4, :oranges=>2, :bananas=>5} {words: %w[I just]}.merge(words: %w[want a group], &:concat) => {:words=>["I", "just", "want", "a", "group"]} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, &:|) # => {"file1"=>5, "file2"=>5} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE, &:&) # => {"file1"=>0, "file2"=>4} # If necessary, old protocol still works: {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |k, o, n| k == :apples ? 0 : o + n } # => {:apples=>0, :oranges=>2, :bananas=>5} ``` As far as I can remember, Ruby core doesn't have methods like this (that change implementation depending on arity of passed callable), but I think I saw this approach in other languages. Can't remember particular examples, but always found this idea appealing. -- https://bugs.ruby-lang.org/

1 year, 3 months

5
8
0 0

[ruby-core:111926] [Ruby master Misc#19357] DevMeeting-2023-02-09

by mame (Yusuke Endoh)

Issue #19357 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19357: DevMeeting-2023-02-09 https://bugs.ruby-lang.org/issues/19357 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2023/02/09 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2023/02/06. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

1 year, 3 months

7
6
0 0

[ruby-core:111992] [Ruby master Bug#19372] Proc objects are not traversed for shareable check during Ractor.make_shareable(prok)

by luke-gru (Luke Gruber)

Issue #19372 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19372: Proc objects are not traversed for shareable check during Ractor.make_shareable(prok) https://bugs.ruby-lang.org/issues/19372 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Proc attr_accessor :obj1 def initialize @obj1 = Object.new end end p = true.instance_eval { Proc.new { puts "hi" } } Ractor.make_shareable(p) p "Obj1 frozen?", Ractor.shareable?(p.obj1) P = p r = Ractor.new do pp = P p pp.obj1 # gives error in debug builds (rb_ractor_confirm_belonging rb_bug() call) end ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

3
5
0 0

[ruby-core:112061] [Ruby master Bug#19385] YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting.

by jwcooper (Justin Cooper)

Issue #19385 has been reported by jwcooper (Justin Cooper). ---------------------------------------- Bug #19385: YJIT panicked while holding VM lock acquired at ./yjit/src/core.rs:1693. Aborting. https://bugs.ruby-lang.org/issues/19385 * Author: jwcooper (Justin Cooper) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) +YJIT [aarch64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Attached is a rust backtrace of an application crashing with a panic with yjit enabled. This is only happening on our sidekiq processes on one of our applications in production. I'm uncertain where in our code it's crashing so far, as it's only crashing once every 20 minutes across 8 sidekiq processes running ~300 jobs/second. Our other applications running with 3.2.0 +yjit are running great on puma and sidekiq. It may be related to, but I'm uncertain: https://bugs.ruby-lang.org/issues/19299 ---Files-------------------------------- backtrace.txt (8.71 KB) -- https://bugs.ruby-lang.org/

1 year, 3 months

4
3
0 0

2024

2023

2022

ruby-core January 2023