finding functions with large stack frames???

Discussion in 'Java' started by Armel, Apr 26, 2007.

  1. Armel

    Armel Guest

    Hello,

    i am trying to find a tool which would (from source code or .jar) tell
    me the size of the stack frame for each java function.
    I have a bug which causes a stack overflow but I do not have any
    information. From the JIT x86 assembler code I could just infer that
    there was a big stack frame (something like 12KB in the crashing
    function call)... if some tool could tell the stack frame size per
    function i'm sure I could get out of this problem in seconds...
    does anyone know any such tool ?

    please help
    Regards
    Armel
     
    Armel, Apr 26, 2007
    #1
    1. Advertising

  2. On 26 Apr 2007 08:58:51 -0700, Armel wrote:
    > i am trying to find a tool which would (from source code or .jar) tell
    > me the size of the stack frame for each java function.


    > I have a bug which causes a stack overflow but I do not have any
    > information.


    Why don't you have any information? The stack dump that comes with the
    StackOverflowError should tell you where to start looking.

    I think it's more likely that your stack *depth* has become too great,
    for example in a recursive method (or set of mutually recursive
    methods), not that one particular method has too many local variables.

    /gordon

    --
     
    Gordon Beaton, Apr 27, 2007
    #2
    1. Advertising

  3. Armel wrote:
    > Hello,
    >
    > i am trying to find a tool which would (from source code or .jar) tell
    > me the size of the stack frame for each java function.
    > I have a bug which causes a stack overflow but I do not have any
    > information. From the JIT x86 assembler code I could just infer that
    > there was a big stack frame (something like 12KB in the crashing
    > function call)... if some tool could tell the stack frame size per
    > function i'm sure I could get out of this problem in seconds...
    > does anyone know any such tool ?
    >
    > please help
    > Regards
    > Armel
    >


    A stack frame overflow from too many function variables as opposed to a
    poorly-written recursive call would require probably on the order of
    hundreds, if not thousands, of local variables per function call.

    Generally, when one gets a stack overflow, one gets the output like this:
    ....
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    at Foo.bar(Foo.java:23)
    ....

    indicating that the termination for recursion is not properly working.
    The best thing to do would be to print diagnostics (e.g. the argument
    list) and squirrel away the error to /dev/null.
     
    Joshua Cranmer, Apr 28, 2007
    #3
  4. Armel

    Armel Guest

    On 28 avr, 01:38, Joshua Cranmer <> wrote:
    > Armel wrote:
    > > Hello,

    >
    > > i am trying to find a tool which would (from source code or .jar) tell
    > > me the size of the stack frame for each java function.
    > > I have a bug which causes a stack overflow but I do not have any
    > > information. From the JIT x86 assembler code I could just infer that
    > > there was a big stack frame (something like 12KB in the crashing
    > > function call)... if some tool could tell the stack frame size per
    > > function i'm sure I could get out of this problem in seconds...
    > > does anyone know any such tool ?

    >
    > > please help
    > > Regards
    > > Armel

    >
    > A stack frame overflow from too many function variables as opposed to a
    > poorly-written recursive call would require probably on the order of
    > hundreds, if not thousands, of local variables per function call.
    >
    > Generally, when one gets a stack overflow, one gets the output like this:
    > ...
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > at Foo.bar(Foo.java:23)
    > ...
    >
    > indicating that the termination for recursion is not properly working.
    > The best thing to do would be to print diagnostics (e.g. the argument
    > list) and squirrel away the error to /dev/null.- Masquer le texte des messages précédents -
    >

    in fact I do not master the executable itself, and I fear that there
    is some eager catch which catches the stack overflow exception and
    simply does nothing with it :-( so no stack trace...

    Armel
     
    Armel, May 3, 2007
    #4
    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. Surinder Singh
    Replies:
    1
    Views:
    1,248
    Richard Bos
    Dec 20, 2007
  2. Casey Hawthorne
    Replies:
    3
    Views:
    1,150
    Flash Gordon
    Nov 1, 2009
  3. Debajit Adhikary
    Replies:
    36
    Views:
    2,397
    Andre Kaufmann
    Feb 10, 2011
  4. Sam Roberts
    Replies:
    1
    Views:
    237
    Yukihiro Matsumoto
    Feb 11, 2005
  5. Kenneth McDonald

    Why stack overflow with such a small stack?

    Kenneth McDonald, Aug 30, 2007, in forum: Ruby
    Replies:
    7
    Views:
    290
    Kenneth McDonald
    Sep 1, 2007
Loading...

Share This Page