Re: possible bug: stack dump with <<-String, #{...} and large loops

Hi,

At Tue, 28 May 2002 17:33:06 +0900,
ts wrote:
>  If I'm right `t1' compile the string and update ruby_scope->local_vars,
>  body->nd_tbl 
> 
>  When `t2' execute the nodes ruby_scope->local_vars is not updated, this
>  can give (in a very special context) a coredump.

Exactly, sigh...

I can't result a coredump yet, this is definitely wrong.

$ cat t.rb
def aa(x=0)
  Thread.pass
  "#{a = b = c = d = e = f = g = Thread.current}"
  p local_variables
end

t1 = Thread.new { aa }
t2 = Thread.new { aa }
t1.join
t2.join

$ ruby t.rb
["x", "a", "b", "c", "d", "e", "f", "g"]
t.rb:4:in `local_variables': NULL pointer given (ArgumentError)
        from t.rb:10:in `join'
        from t.rb:10

And also, this doesn't result SEGV, but very curious and wrong.

$ cat /tmp/t2.rb
def aa(x)
  eval "b = 1" if x
  Thread.pass
  "#{a = Thread.current}"
  p eval "b" if x
end

t1 = Thread.new { aa(false) }
t2 = Thread.new { aa(true) }
t1.join
t2.join

$ ruby t2.rb
#<Thread:0x401ed3fc run>

I can imagine the only way [ruby-core:00053].  Otherwise,
rewriting yylex(), str_extend() and some rules in parse.y to
parse extended strings at compile-time.  However, even if
possible, the latter will change local variable scope:

  "#{a=1}"
  a		#=> 1 not NameError

-- 
Nobu Nakada