Why stack overflow with such a small stack?

Discussion in 'Ruby' started by Kenneth McDonald, Aug 30, 2007.

  1. 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
     
    Kenneth McDonald, Aug 30, 2007
    #1
    1. Advertising

  2. 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
     
    Daniel DeLorme, Aug 31, 2007
    #2
    1. Advertising

  3. 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
     
    Kenneth McDonald, Aug 31, 2007
    #3
  4. --=-7wMIjPcAi0BBbND2LmuI
    Content-Type: multipart/alternative; boundary="=-nABF0ddsLU90pftgbg5Q"


    --=-nABF0ddsLU90pftgbg5Q
    Content-Type: text/plain
    Content-Transfer-Encoding: quoted-printable

    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=20
    > was that I'd made a circular reference to 'values' instead of '@values',=20
    > and the fact that the stack was full of 'values' frames is certainly not=20
    > 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.

    --=20
    Michael T. Richter <> (GoogleTalk:
    )
    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)

    --=-nABF0ddsLU90pftgbg5Q
    Content-Type: text/html; charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
    <HTML>
    <HEAD>
    <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
    <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.12.1">
    </HEAD>
    <BODY>
    On Fri, 2007-31-08 at 10:35 +0900, Kenneth McDonald wrote:
    <BLOCKQUOTE TYPE=3DCITE>
    <PRE>
    <FONT COLOR=3D"#000000">To a newcomer, it's sorta nonobvious, however--it t=
    urned out the problem </FONT>
    <FONT COLOR=3D"#000000">was that I'd made a circular reference to 'values' =
    instead of '@values', </FONT>
    <FONT COLOR=3D"#000000">and the fact that the stack was full of 'values' fr=
    ames is certainly not </FONT>
    <FONT COLOR=3D"#000000">obvious from the above.</FONT>
    </PRE>
    </BLOCKQUOTE>
    <BR>
    A good rule of thumb for avoiding this problem is to name your classes and =
    your variables after nouns and your methods after verbs.<BR>
    <BR>
    So instead of having a method &quot;values&quot; that uses the member &quot=
    ;@values&quot; -- something pretty much guaranteed to lead to trauma at som=
    e point down the road -- make a method &quot;get_values&quot; or &quot;set_=
    values&quot; or &quot;initialize_values&quot; or whatever that uses a membe=
    r called @values.<BR>
    <BR>
    <TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
    <TR>
    <TD>
    -- <BR>
    <B>Michael T. Richter</B> &lt;<A HREF=3D"mailto:">ttmri=
    </A>&gt; (<B>GoogleTalk:</B> )<BR>
    <I>Experts in advanced countries underestimate by a factor of two to four t=
    he ability of people in underdeveloped countries to do anything technical. =
    (Charles P Issawi)</I>
    </TD>
    </TR>
    </TABLE>
    </BODY>
    </HTML>

    --=-nABF0ddsLU90pftgbg5Q--

    --=-7wMIjPcAi0BBbND2LmuI
    Content-Type: application/pgp-signature; name=signature.asc
    Content-Description: This is a digitally signed message part

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (GNU/Linux)

    iD8DBQBG13SyLqyWkKVQ54QRAj8XAJ9G8w2npeOkDF3IhMtBrS64nDgo+QCeLRqw
    6gBM+PO6beEjP8xHu8D/YEA=
    =fgY1
    -----END PGP SIGNATURE-----

    --=-7wMIjPcAi0BBbND2LmuI--
     
    Michael T. Richter, Aug 31, 2007
    #4
  5. 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
     
    Robert Klemme, Aug 31, 2007
    #5
  6. Kenneth McDonald

    Kyle Schmitt Guest

    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
     
    Kyle Schmitt, Aug 31, 2007
    #6
  7. Kenneth McDonald

    Jano Svitok Guest

    On 8/31/07, Kyle Schmitt <> 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.
     
    Jano Svitok, Aug 31, 2007
    #7
  8. 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 <> 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, Sep 1, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?amJpeEBuZXdzZ3JvdXBzLm5vc3BhbQ==?=

    Stack overflow exception

    =?Utf-8?B?amJpeEBuZXdzZ3JvdXBzLm5vc3BhbQ==?=, Apr 20, 2004, in forum: ASP .Net
    Replies:
    5
    Views:
    7,280
    Rick Spiewak
    Apr 22, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    922
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,076
    Smokey Grindel
    Dec 2, 2006
  4. Debajit Adhikary
    Replies:
    36
    Views:
    2,353
    Andre Kaufmann
    Feb 10, 2011
  5. Mark
    Replies:
    2
    Views:
    152
    Vicomte De Valmont
    Oct 28, 2003
Loading...

Share This Page