«

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

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

--

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.

On 28 avr, 01:38, Joshua Cranmer <Pidgeo...@epenguin.zzn.com> 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