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

[ruby-core:111666] [Ruby master Bug#18518] NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large
by Eregon (Benoit Daloze) 05 Jan '23

05 Jan '23

Issue #18518 has been updated by Eregon (Benoit Daloze). FWIW on JRuby: ``` $ ruby -v jruby 9.4.1.0-SNAPSHOT (3.1.0) 2022-12-19 6416265092 OpenJDK 64-Bit Server VM 17.0.5+8 on 17.0.5+8 +jit [x86_64-linux] $ jruby -e 'p(1 << (2**64))' RangeError: bignum too big to convert into `long' $ jruby -e 'p(1 << (2**40))' 1 # JRuby bug ``` RangeError seems a fair error if the RHS does not fit in a 32-bit signed int, probably better than NoMemoryError. ---------------------------------------- Bug #18518: NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large https://bugs.ruby-lang.org/issues/18518#change-101056 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Repro: ```ruby exp = 2**40 # also fails with bignum e.g. 2**64 def exc begin yield rescue NoMemoryError => e p :NoMemoryError end end p exp exc { (1 << exp) } exc { (-1 << exp) } exc { (bignum_value << exp) } exc { (-bignum_value << exp) } ``` Output: ``` $ ruby -v mri_oom.rb ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError [FATAL] failed to allocate memory ``` 3.1.0 seems fine: ``` $ ruby -v mri_oom.rb ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError :NoMemoryError :NoMemoryError :NoMemoryError ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111665] [Ruby master Bug#18518] NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large
by Eregon (Benoit Daloze) 05 Jan '23

05 Jan '23

Issue #18518 has been updated by Eregon (Benoit Daloze). This is still not fixed. I think CRuby should check if RHS is bigger than 2**31 and if so raise an exception immediately instead of taking a lot of time and run into OOM: https://github.com/ruby/ruby/commit/5df711844586312891bb466dbc72265490488d9… ---------------------------------------- Bug #18518: NoMemoryError + [FATAL] failed to allocate memory for twice 1 << large https://bugs.ruby-lang.org/issues/18518#change-101055 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Repro: ```ruby exp = 2**40 # also fails with bignum e.g. 2**64 def exc begin yield rescue NoMemoryError => e p :NoMemoryError end end p exp exc { (1 << exp) } exc { (-1 << exp) } exc { (bignum_value << exp) } exc { (-bignum_value << exp) } ``` Output: ``` $ ruby -v mri_oom.rb ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError [FATAL] failed to allocate memory ``` 3.1.0 seems fine: ``` $ ruby -v mri_oom.rb ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux] mri_oom.rb:7: warning: assigned but unused variable - e 1099511627776 :NoMemoryError :NoMemoryError :NoMemoryError :NoMemoryError ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111664] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by zverok (Victor Shepelev) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by zverok (Victor Shepelev). > The vast majority of classes out there don't define a custom inspect. So Ruby should do something reasonable for these cases. That's true. (I still maintain that it could/should be a good community practice to define better `#inspect`s for better debuggability, because eventual `p self` in pry session of a controller is painful as well, but that's a different question.) ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101054 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111662] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by byroot (Jean Boussier) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by byroot (Jean Boussier). > Note that in the example provided in the original issue I just realized my response was confusing. To clarify I meant `ActionController::Base#inspect`. Which resolve to `Object#inspect`. Controllers simply are the root of a very large object graph. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101053 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111661] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by byroot (Jean Boussier) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by byroot (Jean Boussier). > What if #inspect is very inefficient? In this case a) actually, yes, I believe that it is client's code responsibility Note that in the example provided in the original issue, the slow `#inspect` is simply the default `Object#inspect`. The vast majority of classes out there don't define a custom inspect. So Ruby should do something reasonable for these cases. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101052 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111660] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by zverok (Victor Shepelev) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by zverok (Victor Shepelev). @byroot I am not denying the problem exists or saying it shouldn't be handled (and I acknowledge my Rails remark was inappropriate). I am just saying that the way of fixing it by replacing the object representation with class name breaks many good use cases and, in general, seems less friendly to me. It always felt nice and informative. Interesting to note that the latest Ruby releases tend to add _more_ context for errors (with `did_you_mean` and `error_highlight`), and it is considered a good thing, while this change seems to go in the exactly opposite direction. Actually, thinking a bit more about this, maybe a good compromise solution would be to preserve this change but add `#inspect` of the object to `NoMethodError#detailed_message`?.. It seems to be introduced exactly to handle the balance between the efficiency/brevity of the "core" message and helpfulness. As for the problems which `#inspect` in (any) error message leads to, I believe there are two related but different ones? 1. What if `#inspect` output is too long? Intuitively, I would say that there are many techniques of mechanical shortening of the string to the desired limit. Say, modern IRB handles it quite gracefully (this is a copy-paste of FULL IRB session, the `...` is what it did): ``` >> ary = [{a: 1, foo: :bar}] * 100 => [{:a=>1, :foo=>:bar}, ... ``` 2. What if `#inspect` is very inefficient? In this case a) actually, yes, I believe that it is client's code responsibility (and it is not "sharp knife"-class responsibility, it is rather "if you've implemented `to_s` to return a number, nothing would work properly"), but b) maybe the `detailed_message` idea helps mitigating this, anyway?.. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101051 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111010] [Ruby master Bug#19150] pack/unpack silently ignores unknown directives
by Eregon (Benoit Daloze) 05 Jan '23

05 Jan '23

Issue #19150 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19150: pack/unpack silently ignores unknown directives https://bugs.ruby-lang.org/issues/19150 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- But I believe it should be an error instead. Typically when a parser sees a syntax error it should fail not continue silently. For instance `[1].pack('<L')` succeeds and only emits a warning if `$VERBOSE` is true. This behavior caused confusion in https://github.com/oracle/truffleruby/issues/2791 I think it should fail with an `ArgumentError` instead. Extracted from https://bugs.ruby-lang.org/issues/19108#note-3 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:111651] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by byroot (Jean Boussier) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by byroot (Jean Boussier). > As far as I understand, the problem originates in Rails, which (as they do) doesn't try to follow good practices for #inspect (which is honestly frequently irritating) This absolutely isn't specific to Rails. It can happen with any object that has a large number of reference. Try your `transform_keys` example on a large API payload you received and you'll produce a gigantic error message. "People are holding it wrong" isn't a proper way to address issues. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101041 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111649] [Ruby master Feature#18285] NoMethodError#message uses a lot of CPU/is really expensive to call
by zverok (Victor Shepelev) 05 Jan '23

05 Jan '23

Issue #18285 has been updated by zverok (Victor Shepelev). I understand I am late to the party, but I am extremely concerned with how the discussion in this ticket went. From my understanding: 1. There are many contexts, especially with designing, experimenting, and prototyping with Ruby, where "what object the problem happened with" frequently saves minutes, if not hours, of head-scratching (I give one trivial example below) 2. `#inspect` is a method that is dedicated to reasonable introspection and helping debugging; I believe it kinda implies that the user classes are advised to implement it in an efficient way, so it would be cheap to embed it into diagnostics 3. As far as I understand, the problem originates in Rails, which (as they do) doesn't try to follow good practices for `#inspect` (which is honestly frequently irritating) 4. So, by solving the Rails problem, we are making the life of _all_ Rubyists worse?.. Why I believe it would be worse—in response to: > NoMethodError is typically because the method isn't defined on the class of that instance, and very rarely because it's not defined on the singleton class of that instance (except if it's a Module/Class). Hence showing data of that specific instance seems not so valuable, might as well just show the class. (@Eregon) > > The content of the hash here isn't really helpful, in the context of a `NoMethodError` all I really care about is the type of the object, so why not. (@byroot) Those statements are relevant for typo-originated `NoMethodError` accidents (like `some_hash.deelte`), but not as relevant for duck/dynamic-typing originated ones. Say, in a complicated algorithm working with nested data structures, `undefined method transform_keys for object Array` is significantly worse than `undefined method transform_keys for [{id: 1, name: 'John'}]`. Or, `undefined method punctuation? for TokenGroup` is worse than `undefined method punctuation? for [Token['def'] Token['end']]:TokenGroup` The latter indicates immediately which piece of data defies the initial assumption about the structure (some `users:` are passed as an array, maybe after API version change; some particular fragment of parsed data produced a group of tokens where a singular token was expected), the former requires starting debugging and printing intermediate values. Honestly, I would much rather prefer users to be advised "make sure your `#inspect` is efficient" than make everybody suffer. PS: The [problem of too-long error messages](https://bugs.ruby-lang.org/issues/18285#note-6) is also interesting—but I don't believe that "just never use `#inspect` is a good solution for it either. ---------------------------------------- Feature #18285: NoMethodError#message uses a lot of CPU/is really expensive to call https://bugs.ruby-lang.org/issues/18285#change-101039 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal ---------------------------------------- Hello there! I'm working at Datadog on the ddtrace gem -- https://github.com/DataDog/dd-trace-rb and we ran into this issue on one of our internal testing applications. I also blogged about this issue in <https://ivoanjo.me/blog/2021/11/01/nomethoderror-ruby-cost/>. ### Background While testing an application that threw a lot of `NoMethodError`s in a Rails controller (this was used for validation), we discovered that service performance was very much impacted when we were logging these exceptions. While investigating with a profiler, the performance impact was caused by calls to `NoMethodError#message`, because this Rails controller had a quite complex `#inspect` method, that was getting called every time we tried to get the `#message` from the exception. ### How to reproduce ```ruby require 'bundler/inline' gemfile do source 'https://rubygems.org' gem 'benchmark-ips' end puts RUBY_DESCRIPTION class GemInformation # ... def get_no_method_error method_does_not_exist rescue => e e end def get_runtime_error raise 'Another Error' rescue => e e end def inspect # <-- expensive method gets called when calling NoMethodError#message Gem::Specification._all.inspect end end NO_METHOD_ERROR_INSTANCE = GemInformation.new.get_no_method_error RUNTIME_ERROR_INSTANCE = GemInformation.new.get_runtime_error Benchmark.ips do |x| x.config(:time => 5, :warmup => 2) x.report("no method error message cost") { NO_METHOD_ERROR_INSTANCE.message } x.report("runtime error message cost") { RUNTIME_ERROR_INSTANCE.message } x.compare! end ``` ### Expectation and result Getting the `#message` from a `NoMethodError` should be no costly than getting it from any other exception. In reality: ``` ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux] no method error message cost 115.390 (± 1.7%) i/s - 580.000 in 5.027822s runtime error message cost 6.938M (± 0.5%) i/s - 35.334M in 5.092617s Comparison: runtime error message cost: 6938381.6 i/s no method error message cost: 115.4 i/s - 60130.02x (± 0.00) slower ``` ### Suggested solutions 1. Do not call `#inspect` on the object on which the method was not found (see <https://github.com/ruby/ruby/blob/e0915ba67964d843832148aeca29a1f8244ca7b1/…>) 2. Cache result of calling `#message` after the first call. Ideally this should be done together with suggestion 1. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111646] [Ruby master Bug#19308] Fix `OpenSSL::X509::CertificateError: invalid digest` on CentOS 9 / RHEL 9
by hsbt (Hiroshi SHIBATA) 05 Jan '23

05 Jan '23

Issue #19308 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Closed to Open Oh, sorry. I'm working to upgrade redis server for bugs.ruby-lang.org. Now, It works. ---------------------------------------- Bug #19308: Fix `OpenSSL::X509::CertificateError: invalid digest` on CentOS 9 / RHEL 9 https://bugs.ruby-lang.org/issues/19308#change-101031 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- CentOS 9 / RHEL 9 requires prohibits SHA1 for signing purposes, therefore these specs fail: ~~~ 1) OpenSSL::X509::Name.verify returns true for valid certificate ERROR OpenSSL::X509::CertificateError: invalid digest /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:15:in `sign' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:15:in `block (2 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:4:in `<top (required)>' 2) OpenSSL::X509::Name.verify returns false for an expired certificate ERROR OpenSSL::X509::CertificateError: invalid digest /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:31:in `sign' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:31:in `block (2 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:4:in `<top (required)>' ~~~ I have opened PR [here](https://github.com/ruby/spec/pull/990), but I'd also like see this backported into 3.2, hence also reporting here. -- https://bugs.ruby-lang.org/

1 0