[#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-26 11:02:48 UTC
List: ruby-core #43
Hi,

At Sat, 25 May 2002 18:26:16 +0900,
ts wrote:
>  it will not work.

Oops.  Throw awy the second added line.

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/26 10:54:32
@@ -3074,4 +3074,5 @@ rb_eval(self, n)
 			ruby_sourceline = nd_line(node);
 			ruby_in_eval++;
+			rb_dvar_push(0, 0);
 			list->nd_head = compile(list->nd_head->nd_lit,
 						ruby_sourcefile,

>  Something like this (I *really* don't like it), without the patch to eval.c

Failed at rubicon/language/TestEval.rb.

$ ./i686-linux/miniruby ../rubicon/language/TestEval.rb 
TestEval#testBasicEval F.
TestEval#testEvalModuleBinding .
TestEval#testEvalNameError .
TestEval#testEvalScoping .
TestEval#testEvalWithBinding .
TestEval#testEvalWithProcBinding E.
TestEval#testProcMoreFunWithBinding .
TestEval#testProcNestedBinding .
Time: 0.01597
FAILURES!!!
Test Results:
 Run: 8/8(21 asserts) Failures: 1 Errors: 1
Failures: 1
../rubicon/language/TestEval.rb:7:in `testBasicEval'(TestEval): expected:<nil> but was:<false> (RUNIT::AssertionFailedError)
        from ../rubicon/language/../rubicon_tests.rb:241:in `handleTests'
        from ../rubicon/language/TestEval.rb:135
Errors: 1
../rubicon/language/TestEval.rb:70:in `eval'(TestEval): (eval):1:in `testEvalWithProcBinding': undefined local variable or method `i4' for #<TestEval:0x4023a69c> (NameError)
        from ../rubicon/language/TestEval.rb:70:in `testEvalWithProcBinding'
        from ../rubicon/language/../rubicon_tests.rb:241:in `handleTests'
        from ../rubicon/language/TestEval.rb:135


> pigeon% diff -u node.h.old node.h
> --- node.h.old  Sat May 25 11:01:51 2002
> +++ node.h      Sat May 25 11:01:56 2002
> @@ -267,8 +267,8 @@
>  #define NEW_MASGN(l,r)   rb_node_newnode(NODE_MASGN,l,0,r)
>  #define NEW_GASGN(v,val) rb_node_newnode(NODE_GASGN,v,val,rb_global_entry(v))
>  #define NEW_LASGN(v,val) rb_node_newnode(NODE_LASGN,v,val,local_cnt(v))
> -#define NEW_DASGN(v,val) rb_node_newnode(NODE_DASGN,v,val,0);
> -#define NEW_DASGN_CURR(v,val) rb_node_newnode(NODE_DASGN_CURR,v,val,0);
> +#define NEW_DASGN(v,val) rb_node_newnode(NODE_DASGN,v,val,0)
> +#define NEW_DASGN_CURR(v,val) rb_node_newnode(NODE_DASGN_CURR,v,val,0)
>  #define NEW_IASGN(v,val) rb_node_newnode(NODE_IASGN,v,val,0)
>  #define NEW_CDECL(v,val) rb_node_newnode(NODE_CDECL,v,val,0)
>  #define NEW_CVASGN(v,val) rb_node_newnode(NODE_CVASGN,v,val,0)

You're right.

-- 
Nobu Nakada

In This Thread