finding functions with large stack frames???

[Armel]

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

 

[Gordon Beaton]

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

--

 

[Joshua Cranmer]

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.

 

[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