From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>
Date: 2023-03-14T23:36:46+00:00
Subject: [ruby-core:112886] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_

Issue #4040 has been updated by jeremyevans0 (Jeremy Evans).

Status changed from Closed to Open

I'm reopening this issue.

Originally, when commit:2e7bceb34ea858649e1f975a934ce1894d1f06a6 fixed cfuncs to no longer use the VM stack for large array splats, it was thought to have fully fixed this issue, since the issue was fixed for methods defined in Ruby (iseqs) back in Ruby 2.2.

After additional research, I determined that the same issue affects almost all types of method calls, not just iseq and cfunc calls.  There were two main types of remaining issues, important cases (where large array splat should work) and pedantic cases (where large array splat raised SystemStackError instead of ArgumentError).

Important cases:

```ruby
# bmethod
define_method(:a){|*a|}
a(*1380888.times)

# send
def b(*a); end
send(:b, *1380888.times)

# symproc
:b.to_proc.call(self, *1380888.times)

# method to proc
def d; yield(*1380888.times) end
d(&method(:b))

# method_missing
def self.method_missing(*a); end
not_a_method(*1380888.times)

# Also affects use of C-API with a large number of arguments
```

Pedantic cases:

```ruby
# iseq with only required or optional arguments
def a; end
a(*1380888.times)
def b(_); end
b(*1380888.times)
def c(_=nil); end
c(*1380888.times)

# attr reader/writer
c = Class.new do
  attr_accessor :a
  alias b a=
end.new
c.a(*1380888.times)
c.b(*1380888.times)

# Struct aref/aset
c = Struct.new(:a) do
  alias b a=
end.new
c.a(*1380888.times)
c.b(*1380888.times)
```

I have submitted a pull request to fix the issue: https://github.com/ruby/ruby/pull/7522.  It's fairly invasive, since the use of the VM stack for handling arguments occurs in multiple different places in the VM, and all the different method call handlers need to be updated to support it.  This has a runtime cost, but I'm not sure exactly how much.  I would appreciate if someone could do some benchmarking with it.  We'll need to decide if fixing this issue is worth the potential performance hit (or someone could potentially optimize the approach I used).

----------------------------------------
Bug #4040: SystemStackError with Hash[*a] for Large _a_
https://bugs.ruby-lang.org/issues/4040#change-102402

* Author: runpaint (Run Paint Run Run)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
=begin
 I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice.
 
 I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack...
 
 In IRB, the following is the minimal reproduction of this problem:
 
   Hash[*130648.times.map{ 1 }]; true
 
 I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces:
 
   ruby -e 'Hash[*1380888.times.map{ 1 }]'
 
 I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131.
=end




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/