[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Why stack overflow with such a small stack?

Kenneth McDonald

8/30/2007 10:51:00 PM

I'm getting the following error:

sheet.rb:35:in `values': stack level too deep (SystemStackError)
from sheet.rb:35:in `values'
from sheet.rb:53:in `to_s'
from sheet.rb:52:in `to_s'
from sheet.rb:52:in `map'
from sheet.rb:52:in `to_s'
from sheet.rb:52:in `to_s'
from sheet.rb:52:in `map'
from sheet.rb:52:in `to_s'
from sheet.rb:52:in `to_s'
from sheet.rb:52:in `map'
from sheet.rb:52:in `to_s'
from sheet.rb:92

The output above is given _in full_. Is Ruby truncating the call stack
in this output? If so, how I can I see a larger snapshot of the stack,
so I can trace down where the infinite recursion is really happening? If
not, why am I getting this error?

Thanks,
Ken
25 Answers

Daniel DeLorme

8/30/2007 11:11:00 PM

0

Kenneth McDonald wrote:
> I'm getting the following error:
>
> sheet.rb:35:in `values': stack level too deep (SystemStackError)
> from sheet.rb:35:in `values'
> from sheet.rb:53:in `to_s'
> from sheet.rb:52:in `to_s'
> from sheet.rb:52:in `map'
> from sheet.rb:52:in `to_s'
> from sheet.rb:52:in `to_s'
> from sheet.rb:52:in `map'
> from sheet.rb:52:in `to_s'
> from sheet.rb:52:in `to_s'
> from sheet.rb:52:in `map'
> from sheet.rb:52:in `to_s'
> from sheet.rb:92
>
> The output above is given _in full_. Is Ruby truncating the call stack
> in this output? If so, how I can I see a larger snapshot of the stack,
> so I can trace down where the infinite recursion is really happening? If
> not, why am I getting this error?

Here's one even shorter:
>> def x; x; end; x
SystemStackError: stack level too deep
from (irb):2:in `x'
from (irb):2:in `x'
from (irb):4

Pretty smart of ruby to avoid a gazillion lines of identical output IMHO

Daniel

Terry Poulin

8/31/2007 1:10:00 AM

0

Daniel DeLorme wrote:
> Kenneth McDonald wrote:
>> I'm getting the following error:
>>
>> sheet.rb:35:in `values': stack level too deep (SystemStackError)
>> from sheet.rb:35:in `values'
/* SNIP */
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:92
>>
>> The output above is given _in full_. Is Ruby truncating the call stack
>> in this output? If so, how I can I see a larger snapshot of the stack,
>> so I can trace down where the infinite recursion is really happening? If
>> not, why am I getting this error?
>
> Here's one even shorter:
> >> def x; x; end; x
> SystemStackError: stack level too deep
> from (irb):2:in `x'
> from (irb):2:in `x'
> from (irb):4
>
> Pretty smart of ruby to avoid a gazillion lines of identical output IMHO
>
> Daniel
>
>

It's nice to see a smart little gem in them thar rubies ;-)


I remmeber how long it took for a C Program to crash from the number of
function calls.... Dang thats a good Ruby.


TerryP.


--

Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ip...

Kenneth McDonald

8/31/2007 1:35:00 AM

0

Daniel DeLorme wrote:
> Kenneth McDonald wrote:
>> I'm getting the following error:
>>
>> sheet.rb:35:in `values': stack level too deep (SystemStackError)
>> from sheet.rb:35:in `values'
>> from sheet.rb:53:in `to_s'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:52:in `map'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:52:in `map'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:52:in `map'
>> from sheet.rb:52:in `to_s'
>> from sheet.rb:92
>>
>> The output above is given _in full_. Is Ruby truncating the call
>> stack in this output? If so, how I can I see a larger snapshot of
>> the stack, so I can trace down where the infinite recursion is really
>> happening? If not, why am I getting this error?
>
> Here's one even shorter:
> >> def x; x; end; x
> SystemStackError: stack level too deep
> from (irb):2:in `x'
> from (irb):2:in `x'
> from (irb):4
>
> Pretty smart of ruby to avoid a gazillion lines of identical output IMHO
>
> Daniel
>
>
To a newcomer, it's sorta nonobvious, however--it turned out the problem
was that I'd made a circular reference to 'values' instead of '@values',
and the fact that the stack was full of 'values' frames is certainly not
obvious from the above.

Ken

Michael T. Richter

8/31/2007 1:54:00 AM

0

On Fri, 2007-31-08 at 10:35 +0900, Kenneth McDonald wrote:

> To a newcomer, it's sorta nonobvious, however--it turned out the problem
> was that I'd made a circular reference to 'values' instead of '@values',
> and the fact that the stack was full of 'values' frames is certainly not
> obvious from the above.


A good rule of thumb for avoiding this problem is to name your classes
and your variables after nouns and your methods after verbs.

So instead of having a method "values" that uses the member "@values" --
something pretty much guaranteed to lead to trauma at some point down
the road -- make a method "get_values" or "set_values" or
"initialize_values" or whatever that uses a member called @values.

--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
Experts in advanced countries underestimate by a factor of two to four
the ability of people in underdeveloped countries to do anything
technical. (Charles P Issawi)

Robert Klemme

8/31/2007 6:02:00 AM

0

On 31.08.2007 03:54, Michael T. Richter wrote:
> On Fri, 2007-31-08 at 10:35 +0900, Kenneth McDonald wrote:
>> To a newcomer, it's sorta nonobvious, however--it turned out the problem
>> was that I'd made a circular reference to 'values' instead of '@values',
>> and the fact that the stack was full of 'values' frames is certainly not
>> obvious from the above.
>
> A good rule of thumb for avoiding this problem is to name your classes
> and your variables after nouns and your methods after verbs.
>
> So instead of having a method "values" that uses the member "@values" --
> something pretty much guaranteed to lead to trauma at some point down
> the road -- make a method "get_values" or "set_values" or
> "initialize_values" or whatever that uses a member called @values.

Although I agree in general (i.e. using verbs for method names) I
heavily disagree with your last advice: according to Ruby's convention a
getter is named "foo" and a setter "foo=". This is implemented in attr*
methods and IMHO it is not advisable to leave this convention.

Also, there are good reasons to use getters instead of instance
variables, namely that you get more abstraction (there doesn't
necessarily have to be a member variable of that name).

Kind regards

robert

Kyle Schmitt

8/31/2007 2:26:00 PM

0

Heh, This is one of the few languages I haven't had that happen to to
me on before.

Lisp, C, C++, Perl... but I haven't caused one of those on _ruby_ before.

Now, if you've really intended to do recursion, try making it tail recursive.

Err... Ruby does optimize for tail recursion, right?

--Kyle

Jano Svitok

8/31/2007 4:32:00 PM

0

On 8/31/07, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:
> Heh, This is one of the few languages I haven't had that happen to to
> me on before.
>
> Lisp, C, C++, Perl... but I haven't caused one of those on _ruby_ before.
>
> Now, if you've really intended to do recursion, try making it tail recursive.
>
> Err... Ruby does optimize for tail recursion, right?

I'm not sure, after some googling it seems that 1.8 doesn't and YARV
might partially optimize.

Kenneth McDonald

9/1/2007 4:21:00 AM

0

Unless I read otherwise, I usually assume that languages don't optimize
tail recursion. If you look at typical codebases, using tail recursion
instead of some sort of higher-level looping construct, or even a simple
basic loop, is really an academic curiosity. It doesn't normally make
code clearer or easier to write, and most people, even those who are
aware of it, don't use it. (In fact people who really know about it
often tend to avoid it because they also know of the overhead induced by
function calling.) So why bother optimizing for this case?

Ken


Jano Svitok wrote:
> On 8/31/07, Kyle Schmitt <kyleaschmitt@gmail.com> wrote:
>
>> Heh, This is one of the few languages I haven't had that happen to to
>> me on before.
>>
>> Lisp, C, C++, Perl... but I haven't caused one of those on _ruby_ before.
>>
>> Now, if you've really intended to do recursion, try making it tail recursive.
>>
>> Err... Ruby does optimize for tail recursion, right?
>>
>
> I'm not sure, after some googling it seems that 1.8 doesn't and YARV
> might partially optimize.
>
>
>


nttn

2/22/2011 11:04:00 PM

0

On Feb 22, 5:58 pm, ":))" <bennypo...@yahoo.com> wrote:
> On Tue, 22 Feb 2011 14:53:40 -0800 (PST), nttn <nttn1...@yahoo.com>
> wrote:
>
> >ukie ... ba?n kia cho Nga ... ba?n na`y sao ho^?ng tha^'y JoJ ho^ la`
> >cho ai va^.y ???
>
> >shy, are you???
>
> >:)))
>
> Cha('c ba`i na`y ta(.ng cho co^ na`ng ddo^'c to*` Nach ro^`i
>
> ;-)))
>
> How' ve you been Nana ?  Hope everything is going well for this year
> heh. :)
>
> Wonderful afternooon...

hello Pooh ... :)))

va^~n ba^.n ... va` co`n ba^.n ho+n nga`y xu+a ddo' Pooh o+i ...

cho ne^n ca'i tho+`i thu+'c gia^'c nu+?a dde^m cha('c coi nhu+ ta.m
he^'t :)

gio+` le^'t ve^` ddu+o+.c dde^'n nha` la` Nga chi? muo^'n bo` luo^n
va`o giu+o+`ng ...

yet ... i'm a lucky one ... to have my family and my parents living so
close to one another ...

can't complain ... :))

co`n Pooh thi` va^~n ta` ta` chu+' ???

Nana


>
>
>
> >On Feb 21, 11:57 pm, "saint joj" <jupiter...@gmail.com> wrote:
> >> ...anh tro+? dia` tha(m em :-))))
>
> >>http://www.jupiterean.com/music/Mine/muaxuand...

:))

2/22/2011 11:12:00 PM

0

On Tue, 22 Feb 2011 15:04:13 -0800 (PST), nttn <nttn1996@yahoo.com>
wrote:

>yet ... i'm a lucky one ... to have my family and my parents living so
>close to one another ...
>
>can't complain ... :))
>
>co`n Pooh thi` va^~n ta` ta` chu+' ???
>
>Nana
-----------------------------------------------------------------------------------------------------
Yeah, va^~n ta` ta` tho^i Nana a` !

La^u la^u ca?m tha^'y ye^'u thi` va`o SCV ddi kha'm be^.nh Dr. Tri',
Dr. Nach....general check up.

:-)))

Take good care Nana ha !