- ruby-dev - ml.ruby-lang.org

[ruby-dev:52056] [Ruby master Bug#19537] Regexp caching algorithm since v3.2.0 causes invalid memory access
by jeremyevans0 (Jeremy Evans) 25 Oct '23

25 Oct '23

Issue #19537 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Fixed in commit:a1c2c274eebcc2a5275b677ebf94a8dbff380770 ---------------------------------------- Bug #19537: Regexp caching algorithm since v3.2.0 causes invalid memory access https://bugs.ruby-lang.org/issues/19537#change-105083 * Author: jj1uzh (Futa Miyachi) * Status: Closed * Priority: Normal * Assignee: make_now_just (Hiroya Fujinami) * ruby -v: ruby 3.3.0dev (2023-03-17T09:50:55Z master c65d7b4bea) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Some types of regular expressions causes invalid memory access on `#match`. Length of strings to match does not matter. For example, for regex `/^([ab]{1,3})(a?)*$/`, `"aac"` can crash ruby. This bug may be caused in caching algorithm since v3.2.0. v3.1.3 is safe as far as I checked. Environments: Linux 6.2.6-arch1-1 x86-64, 16GB RAM Reproduce Process: ``` $> ruby -e 'p /^([ab]{1,3})(a?)*$/.match "aac"' -e:1: [BUG] Segmentation fault at 0x0000560315993d90 ruby 3.3.0dev (2023-03-17T09:50:55Z master c65d7b4bea) [x86_64-linux] ... ``` Whole output is attached as output.txt. Note that result may be `nil` correctly sometimes. Part of backtrace: ``` #5 0x000055ff30b71ecb in sigsegv (sig=11, info=0x55ff31bd0e70, ctx=0x55ff31bd0d40) at ../signal.c:964 #6 <signal handler called> #7 reset_match_cache (num_cache_table=<optimized out>, num_cache_size=3, table=0x55ff31e2d930, match_cache=0x55ff31e2aec0 "\300\f", pos=2, pend=<optimized out>, pbegin=0x55ff31dc7202 ">\030", reg=0x55ff31e199b0) at ../regexec.c:1292 #8 match_at (reg=reg@entry=0x55ff31e199b0, str=str@entry=0x7fb176c7f148 "aac", end=<optimized out>, end@entry=0x7fb176c7f14b "", sstart=sstart@entry=0x7fb176c7f148 "aac", sprev=<optimized out>, msa=msa@entry=0x7ffe40153d30) at ../regexec.c:3486 ``` ---Files-------------------------------- output.txt (17.4 KB) ruby-19537.patch (1.77 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52055] There is an overdue payment under your name. Please, settle your debts ASAP.
by ruby-dev＠ruby-lang.org 16 Oct '23

16 Oct '23

Hi! Sadly, there are some bad news that you are about to hear. About few months ago I have gained a full access to all devices used by you for internet browsing. Shortly after, I started recording all internet activities done by you. Below is the sequence of events of how that happened: Earlier I purchased from hackers a unique access to diversified email accounts (at the moment, it is really easy to do using internet). As you can see, I managed to log in to your email account without breaking a sweat: (ruby-dev(a)ruby-lang.org) Within one week afterwards, I installed a Trojan virus in your Operating Systems available on all devices that you utilize for logging in your email. To be frank, it was somewhat a very easy task (since you were kind enough to open some of links provided in your inbox emails). I know, you may be thinking now that I'm a genius.....^^) With help of that useful software, I am now able to gain access to all the controllers located in your devices (e.g., video camera, keyboard, microphone and others). As result, managed to download all your photos, personal data, history of web browsing and other info to my servers without any problems. Moreover, I now have access to all accounts in your messengers, social networks, emails, contacts list, chat history - you name it. My Trojan virus continues refreshing its signatures in a non-stop manner (because it is operated by driver), hence it remains undetected by any antivirus software installed in your PC or device. So, I guess now you finally understand the reason why I could never be caught until this very letter... During the process of your personal info compilation, I could not help but notice that you are a huge admirer and regular guest of websites with adult content. You endure a lot of pleasure while checking out porn websites, watching nasty porn movies and reaching breathtaking orgasms. Let me be frank with you, it was really hard to resist from recording some of those naughty solo scenes with you in main role and compiling them in special videos that expose your masturbation sessions, which end with you cumming. In case if you still have doubts, all I need is to click my mouse and all those nasty videos with you will be shared to friends, colleagues, and relatives of yours. Moreover, nothing stops me from uploading all that hot content online, so all public can watch it too. I sincerely hope, you would really not prefer that to happen, keeping in mind all the dirty things you like to watch, (you certainly know what I mean) it will completely ruin your reputation. However, don't worry, there is still a way to resolve this: You need to carry out a $1350 USD transfer to my wallet (equivalent amount in bitcoins depending on exchange rate at the moment of funds transfer), hence upon receiving the transaction, I will proceed with deleting all the filthy videos with you in main role. Afterwards, we can forget about this unpleasant accident. Furthermore, I guarantee that all the malicious software will also be erased from your devices and accounts. Mark my words, I never lie. That is a great bargain with a low price, I assure you, because I have spent a lot of effort while recording and tracking down all your activities and dirty deeds during a long period of time. In case if you have no idea how to buy and transfer bitcoins - feel free to check the related info on the internet. Here is my bitcoin wallet for your reference: 15L57f8 G22cPmD tq2devc Qw6J4Sb C8EX8b Attention please! I have specified my Bitcoin wallet with spaces, please make sure that you key-in my bitcoin address without spaces to be sure that your coins successfully reach my wallet! From now on, you have only 48 hours and countdown has started once you opened this very email (in other words, 2 days). The following list contains things you should definitely abstain from doing or even attempting: ~>> Abstain from trying to reply this email (since the email is generated inside your inbox alongside with return address). ~>> Abstain from trying to call or report to police or any other security services. In addition, it's a bad idea if you want to share it with your friends, hoping they would help. If I happen to find out (knowing my awesome skills, it can be done effortlessly, because I have all your devices and accounts under my control and unceasing observation) - kinky videos of yours will be share to public the same day. ~>> Abstain from trying to look for me - that would not lead anywhere either. Cryptocurrency transactions are absolutely anonymous and cannot be tracked. ~>> Abstain from reinstalling your OS on devices or throwing them away. That would not solve the problem as well, since all your personal videos are already uploaded and stored at remote servers. Things you may be confused about: ~>> That your funds transfer won't be delivered to me. Chill, I can track down any transactions right away, so upon funds transfer I will receive a notification as well, since I still control your devices (my trojan virus has ability of controlling all processes remotely, just like TeamViewer). ~>> That I am going to share your dirty videos after receiving money transfer from you. Here you need to trust me, because there is absolutely no point to still bother you after receiving money. Moreover, if I really wanted all those videos would be available to public long time ago! I believe we can still handle this situation on fair terms! Here is my last advice to you... in future you better ensure you stay away from this kind of situations! My advice - don't forget to regularly update your passwords to feel completely secure.

1 0

[ruby-dev:52054] [Ruby master Feature#18573] Object#pack1
by mame (Yusuke Endoh) 13 Oct '23

13 Oct '23

Issue #18573 has been updated by mame (Yusuke Endoh). If we introduce a new method for this, I think it would be better to design a more descriptive API instead of reusing a hacky pack format directive, such as `0x1234.to_binary_string(4, endian: :big) #=> "\x00\x00\x12\x34"`. ---------------------------------------- Feature #18573: Object#pack1 https://bugs.ruby-lang.org/issues/18573#change-104913 * Author: os (Shigeki OHARA) * Status: Open * Priority: Normal ---------------------------------------- # 概要 String#unpack1 の逆の Object#pack1 が欲しい。 # 背景 Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。 ``` ruby [codepoint].pack('U') [digest].pack('m0') [mail_body].pack('M') [ip_address].pack('N') ``` 標準添付ライブラリーなどを眺めてみてもチラホラあるようです。ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。 # 提案 String#unpack に対して String#unpack1 というメソッドがありますが、 Array#pack に対する Object#pack1 というメソッドを提案します。イメージとしては以下のコードのような感じです。 ``` ruby class Object def pack1(template, option = {}) [self].pack(template, **option) end end ``` # 議論・課題 * Object で良いかどうかは議論の余地があろうかと思います * メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52053] [Ruby master Feature#18573] Object#pack1
by tenderlovemaking (Aaron Patterson) 12 Oct '23

12 Oct '23

Issue #18573 has been updated by tenderlovemaking (Aaron Patterson). matz (Yukihiro Matsumoto) wrote in #note-7: > Array.pack1 is unlikely because there is no connection between the responsibilities of the method and the Array class. I also disagree with String.pack1 for the same reason. > The most natural candidate is Object#pack1, but I question the need to pollute the namespace for this trivial method. > > Matz. Feature #18897 introduced a specialized instruction for Array#hash, but it created a new instruction called `opt_newarray_send`. I think we could leverage that instruction for the case of an array literal + pack. That would avoid the array creation. I will try to make a patch. ---------------------------------------- Feature #18573: Object#pack1 https://bugs.ruby-lang.org/issues/18573#change-104894 * Author: os (Shigeki OHARA) * Status: Open * Priority: Normal ---------------------------------------- # 概要 String#unpack1 の逆の Object#pack1 が欲しい。 # 背景 Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。 ``` ruby [codepoint].pack('U') [digest].pack('m0') [mail_body].pack('M') [ip_address].pack('N') ``` 標準添付ライブラリーなどを眺めてみてもチラホラあるようです。ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。 # 提案 String#unpack に対して String#unpack1 というメソッドがありますが、 Array#pack に対する Object#pack1 というメソッドを提案します。イメージとしては以下のコードのような感じです。 ``` ruby class Object def pack1(template, option = {}) [self].pack(template, **option) end end ``` # 議論・課題 * Object で良いかどうかは議論の余地があろうかと思います * メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52052] [Ruby master Feature#18573] Object#pack1
by matz (Yukihiro Matsumoto) 12 Oct '23

12 Oct '23

Issue #18573 has been updated by matz (Yukihiro Matsumoto). Array.pack1 is unlikely because there is no connection between the responsibilities of the method and the Array class. I also disagree with String.pack1 for the same reason. The most natural candidate is Object#pack1, but I question the need to pollute the namespace for this trivial method. Matz. ---------------------------------------- Feature #18573: Object#pack1 https://bugs.ruby-lang.org/issues/18573#change-104876 * Author: os (Shigeki OHARA) * Status: Open * Priority: Normal ---------------------------------------- # 概要 String#unpack1 の逆の Object#pack1 が欲しい。 # 背景 Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。 ``` ruby [codepoint].pack('U') [digest].pack('m0') [mail_body].pack('M') [ip_address].pack('N') ``` 標準添付ライブラリーなどを眺めてみてもチラホラあるようです。ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。 # 提案 String#unpack に対して String#unpack1 というメソッドがありますが、 Array#pack に対する Object#pack1 というメソッドを提案します。イメージとしては以下のコードのような感じです。 ``` ruby class Object def pack1(template, option = {}) [self].pack(template, **option) end end ``` # 議論・課題 * Object で良いかどうかは議論の余地があろうかと思います * メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52051] [Ruby master Feature#18573] Object#pack1
by Eregon (Benoit Daloze) 06 Oct '23

06 Oct '23

Issue #18573 has been updated by Eregon (Benoit Daloze). `Array.pack1(obj, format) -> String` sounds weird since there is nothing about Array in there. I think `String.pack1(format, obj)` is the best option. (`String#pack1(obj)` is confusing because of existing `Array#pack(format)` which has the reverse order). (IMO this is something a JIT should optimize but I understand that's hard on CRuby). ---------------------------------------- Feature #18573: Object#pack1 https://bugs.ruby-lang.org/issues/18573#change-104830 * Author: os (Shigeki OHARA) * Status: Open * Priority: Normal ---------------------------------------- # 概要 String#unpack1 の逆の Object#pack1 が欲しい。 # 背景 Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。 ``` ruby [codepoint].pack('U') [digest].pack('m0') [mail_body].pack('M') [ip_address].pack('N') ``` 標準添付ライブラリーなどを眺めてみてもチラホラあるようです。ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。 # 提案 String#unpack に対して String#unpack1 というメソッドがありますが、 Array#pack に対する Object#pack1 というメソッドを提案します。イメージとしては以下のコードのような感じです。 ``` ruby class Object def pack1(template, option = {}) [self].pack(template, **option) end end ``` # 議論・課題 * Object で良いかどうかは議論の余地があろうかと思います * メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52050] [Ruby master Feature#18573] Object#pack1
by jeremyevans0 (Jeremy Evans) 05 Oct '23

05 Oct '23

Issue #18573 has been updated by jeremyevans0 (Jeremy Evans). I developed a patch for this that implemented the feature using `Array.pack1` and was going to create a new feature request for it, but I'm glad to see there already is an existing feature request for it. Here's my pull request for it: https://github.com/ruby/ruby/pull/8598 ---------------------------------------- Feature #18573: Object#pack1 https://bugs.ruby-lang.org/issues/18573#change-104824 * Author: os (Shigeki OHARA) * Status: Open * Priority: Normal ---------------------------------------- # 概要 String#unpack1 の逆の Object#pack1 が欲しい。 # 背景 Array#pack というメソッドがありますが、レシーバーの Array の要素数が 1 つしかないことが良くあります。 ``` ruby [codepoint].pack('U') [digest].pack('m0') [mail_body].pack('M') [ip_address].pack('N') ``` 標準添付ライブラリーなどを眺めてみてもチラホラあるようです。ですが、このようなケースで変換対象のオブジェクトをわざわざ Array でくるまなくてはいけないというのは面倒な気もします。 # 提案 String#unpack に対して String#unpack1 というメソッドがありますが、 Array#pack に対する Object#pack1 というメソッドを提案します。イメージとしては以下のコードのような感じです。 ``` ruby class Object def pack1(template, option = {}) [self].pack(template, **option) end end ``` # 議論・課題 * Object で良いかどうかは議論の余地があろうかと思います * メソッド名が pack1 で良いかはわかりませんが、他とかぶる可能性は低いかと思います -- https://bugs.ruby-lang.org/

1 0

[ruby-dev:52034] [Ruby master Bug#19792] arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する
by koke2y 30 Sep '23

30 Sep '23

Issue #19792 has been reported by koke2y (優樹纐纈). ---------------------------------------- Bug #19792: arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する https://bugs.ruby-lang.org/issues/19792 * Author: koke2y (優樹纐纈) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## 実行環境 Docker version: Docker version 24.0.2, build cb74dfc Docker image: ruby:3.2.2-alpine3.18 ホスト環境 - chip: Apple M2 Max - OS version: Version 13.4 ## 発生した事象上記の環境で下記のスクリプトを実行すると、segmentation faultが発生しました。 ``` str = 'a' * 100_000_000 hash = { x: { y: { z: str } } } p hash ``` ``` 81a3dc0d38e8:/api# ruby test.rb test.rb:11: [BUG] Segmentation fault at 0x0000ffff84e454a0 ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] -- Control frame information ----------------------------------------------- c:0006 p:---- s:0022 e:000021 CFUNC :inspect c:0005 p:---- s:0019 e:000018 CFUNC :inspect c:0004 p:---- s:0016 e:000015 CFUNC :inspect c:0003 p:---- s:0013 e:000012 CFUNC :p c:0002 p:0029 s:0008 E:001cc0 EVAL test.rb:11 [FINISH] c:0001 p:0000 s:0003 E:000da0 DUMMY [FINISH] ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-dev:52045] [Ruby master Bug#19902] strftimeの返り値のascii_only?が間違っていることがある
by znz (Kazuhiro NISHIYAMA) 30 Sep '23

30 Sep '23

Issue #19902 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #19902: strftimeの返り値のascii_only?が間違っていることがある https://bugs.ruby-lang.org/issues/19902 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-jp slack で tompng さんの調査によると以下のように `Regexp.esacpe` が変になる原因は `t.ascii_only? #=> true` になっていることでした。 ``` irb(main):053> t = Time.now.strftime(u='あ') => "あ" irb(main):054> t==u => true irb(main):055> t.encoding==u.encoding => true irb(main):056> Regexp.escape(t) => "\xE3\x81\x82" irb(main):057> Regexp.escape(u) => "あ" ``` git bisect で `make miniruby && ./miniruby -ve "p Time.now.strftime('%Y年').ascii_only?"` をしつつ調べてみると、https://github.com/ruby/ruby/commit/f34280ec6b684eeb21ef3336c700… から `true` になってしまっているようです。 -- https://bugs.ruby-lang.org/

4 3

[ruby-dev:52044] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by kddnewton (Kevin Newton) 22 Sep '23

22 Sep '23

Issue #17925 has been updated by kddnewton (Kevin Newton). I agree with @yui-knk here, I think this is definitely a choice and at this point can't be changed. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104733 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`,　can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/

1 0