[#42] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

32 messages 2002/05/25
[#43] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#45] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#46] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/26

Hi,

[#47] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#48] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/26

>>>>> "t" == ts <decoux@moulon.inra.fr> writes:

[#49] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#50] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#51] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#52] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#53] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#54] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#55] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/27

Hi,

[#56] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/27

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#57] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/28

Hi,

[#65] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/28

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#84] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/29

Hi,

[#92] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/05/29

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#67] The warns-a-thon continues... — Sean Chittenden <sean@...>

I'm feeling left out in this race to clobber warnings!!! Attached are

19 messages 2002/05/28

[#104] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...>

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

29 messages 2002/05/30
[#105] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/05/30

Hi,

[#125] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#126] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#127] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/04

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

[#130] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/04

Hi,

[#132] Re: possible bug: stack dump with <<-String, #{...} and large loops — nobu.nokada@... 2002/06/05

Hi,

[#134] Re: possible bug: stack dump with <<-String, #{...} and large loops — ts <decoux@...> 2002/06/05

>>>>> "n" == nobu nokada <nobu.nokada@softhome.net> writes:

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

From: nobu.nokada@...
Date: 2002-05-27 11:46:50 UTC
List: ruby-core #53
Hi,

At Mon, 27 May 2002 19:38:22 +0900,
ts wrote:
> n>   begin "#{a=1; raise}"; rescue; end
> n>   p "#{a}"
> 
>      begin "#{a = 1:}"; rescue SyntaxError; end
>      eval "a = 12"

Oops, RVarmap's in compilation time should be swept away at a
compile error.  Also the following eval's should err either.

  begin "#{a = b = 1:}"; rescue SyntaxError; end
  eval "p a"
  eval "p b"

> n> [ruby-core:00047] disposes only a dvar header
> 
>  `a' is a dynamic variable, no ?

I meant RVarmap whose id is 0 by "a dvar header", it's placed
at the top of ruby_dyna_vars list.  Other dvars are inserted
after it by dvar_asgn_curr().


Index: eval.c
===================================================================
RCS file: /cvs/ruby/src/ruby/eval.c,v
retrieving revision 1.295
diff -u -2 -p -r1.295 eval.c
--- eval.c	2002/05/21 05:39:18	1.295
+++ eval.c	2002/05/27 11:24:44
@@ -3061,6 +3061,8 @@ rb_eval(self, n)
 	    VALUE str, str2;
 	    NODE *list = node->nd_next;
+	    struct RVarmap *vars = ruby_dyna_vars;
 
 	    str = rb_str_new3(node->nd_lit);
+	    if (!ruby_dyna_vars) rb_dvar_push(0, 0);
 	    while (list) {
 		if (list->nd_head) {
@@ -3080,4 +3082,11 @@ rb_eval(self, n)
 			ruby_in_eval--;
 			if (ruby_nerrs > 0) {
+			    struct RVarmap *vp = ruby_dyna_vars;
+			    ruby_dyna_vars = vars;
+			    while (vp && vp != vars) {
+				struct RVarmap *tmp = vp;
+				vp = vp->next;
+				rb_gc_force_recycle((VALUE)tmp);
+			    }
 			    compile_error("string expansion");
 			}


-- 
Nobu Nakada

In This Thread