Re: java.lang.StackOverflowError

Pankaj Agarwal wrote:
>
> Hello,
>
> I am running into a Stack memory overflow problem with a java program 
> I am running, and was hoping someone on this list may have experienced 
> this problem before and can provide some help.  In my code I have a 
> recursion method, and after several calls of this method, I get a 
>  java.lang.StackOverflowError.  I can catch the error in a Throwable 
> catch block, but cannot get a stack trace (a null is printed).  There 
> are a couple of parameters which I have
> used to try and increase the stack memory size (-Xss and -Xoss), but 
> it did not help.
>
> I would appreciate any help to resolve this problem.  Is there a way 
> to find out the stack memory available in the Java API?
I don't think so, however I think you can compute it if you can keep a 
recursion depth counter (see below).

But I think the first thing to realize is that with Java Standard 
Edition versions up through 5 (formerly 1.5) the thread invoking your 
"main method" may have been created along with the process executing 
Java: it can't be modified after the fact. That is, by the time the Java 
implementation parses the -Xss switch it's too late to do anything for 
the initial thread. This is true for Sun's implementation for sure 
(Change Request "CR" 6316197: "fixed" in SE version 6 [fixed for people 
that aren't dependent on large main method stack limits!]), but I can't 
speak for other implementations not closely based on the Sun source 
code. I suspect this behavior had to do with various bad things that 
happened when Java implementers tried to get away with the current 
typical default per-thread stack limit (some fraction of a megabyte, if 
I recall correctly). As Java matured and people tried to run dozens, 
then hundreds, then thousands of threads, the default had to find the 
happy medium between too small and two large.

So the first thing I'd try, if you haven't already, is to spawn a child 
thread and have that thread execute your recursive code. Then see if 
-Xss gives you relief.

If this is a blind alley, next I would try is to "signal" another thread 
via something like a volatile static boolean field and then go into an 
infinite loop. Then have the second thread watch the boolean field 
(doing Thread.sleep calls to avoid significant overhead). When the 2nd 
thread sees the field become true it can get a stack trace or other 
information.

The other interesting thing to communicate to the 2nd thread would be 
the recursion depth. Then you could pass two values of -Xss different 
from each other, subtract the difference and divide that by the 
difference in maximum depth at the point of program failure.

-Pete


>
> Thanks,
>
> - Pankaj
>
> Pankaj Agarwal
> Duke Bioinformatics Shared Resource
> Duke Comprehensive Cancer Center
> Duke University
> 919-681-6573
> [email protected]
> ------------------------------------------------------------------------
>
> _______________________________________________
> Juglist mailing list
> [email protected]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
>