java.lang.StackOverflowError

This seems to happen only when debug logging is enabled for the Javaflow classes.  Hence you can workaround the bug by disabling that, e.g. by using the following for Log4j:

log4j.logger.org.apache.commons.javaflow=info

HTH,

Lucian

Hi,

We had the same problem with a stackOverflow. But we had no logging on other classes than our own. When we removed that logging, all went ok. So it's not just logging on javaflow classes that gives the problem. Bud anyway, removing the logging did help!

Thanks for the suggestion!

Mathijs Hobijn

Can someone who has permanently solved this problem please provide some detail on how they sovled it? We have one Linux server running Tomcat 6.0.32 and JVM 1.6.0_26 that we cannot solve this on; the server does not have any debug logging enabled, and we have tried to explicitly "disabled" such logging as suggested in this discussion. The offending report (which includes an overflowing subreport) works fine on similar servers (although with slightly older versions of the 1.6 JVM). We have not been able to identify anything else different about the particular server that experiences the StackOverflowError.

Alternatively or additionally, if someone could tell me how to find a copy of the javaflow source code aligned with the distribution of Jasper Reports I would be glad to do some further research within the code. The javaflow source at http://svn.apache.org/repos/asf is newer.

-Tad

Never got a resolution. We swiched back to using the multi-threaded runner. My take on this is that Jasper got "excited" about the continuation solution for awhile (per the Ultimate Guide) but abandoned seeking a solid resolution for this problem when it appeared to be out of the scope of Jasper's code.

See: http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=92700#92700

Ok, so I checked out the latest source of Javaflow, as it seems the developers improved logging according to the SVN commit message. After I built/deployed it, I am getting a new Exception:

 
Caused by: net.sf.jasperreports.engine.JRRuntimeException: java.lang.NoSuchMethodError: org/apache/commons/javaflow/Continuation.suspend()V
    at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:782)
    at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:331)
    at net.sf.jasperreports.engine.fill.JRFillFrame.prepare(JRFillFrame.java:219)
    at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:331)
    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:386)
    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:358)
    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2059)
    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:778)
    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:288)
    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:151)
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:932)
    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:845)
    at net.sf.jasperreports.engine.fill.JRFiller.fill(JRFiller.java:87)
    at net.sf.jasperreports.engine.JasperFillManager.fill(JasperFillManager.java:446)
    at net.sf.jasperreports.engine.JasperRunManager.runToPdf(JasperRunManager.java:331)
    at net.sf.jasperreports.engine.JasperRunManager.runReportToPdf(JasperRunManager.java:796)

@lucianc: can you please help out and tell me how to change the Continuation.suspend method, so that it works for JR? Basically, what return type is required? Thanks in advance.

This problem has returned for me as well. Very difficult to consistently reproduce. I'm running Jasper through a WAR and JAR inside an EAR file for deployment. I have the log4j.properties file in /WEB-INF/classes inside my WAR file and /lib in my EAR file. And I am still experiencing this issue. toffer, are you experiencing this issue anymore? How are you deploying Jasper?

We also ran into this issue. After some debugging I found the root cause.

The issue is logger related, because it is caused by debug logging in JavaFlow. In consequence, the issue does not occur if your logger does not log debug messages coming from JavaFlow.

What happens is that when JavaFlow pops or pushes an object onto their stack they make a debug message containing hash code of the object. Unfortunatelly, if you have a subreport that overflows, one of these objects will be a HashMap which contains a reference to itself. Trying to get a hash code of such a map results in an infinite loop, because hash code of a map is a sum of hash codes of its items. (See http://docs.oracle.com/javase/7/docs/api/java/util/AbstractMap.html#hashCode()).

I filed a bug for JavaFlow as I believe they should try to handle this specific situation - https://issues.apache.org/jira/browse/SANDBOX-477. Since the project is dormant, I would not expect anyone to deal with it in the near future. Source code for JavaFlow 20060411, which is used by Jasper Reports, can be downloaded e.g. from here: http://olex.openlogic.com/packages/commons-javaflow/20060411.

The question is why does Jasper Reports create such a dangerous object. JavaDoc of java.util.Map says "While it is permissible for a map to contain itself as a value, extreme caution is advised: the equals and hashCode methods are no longer well defined on such a map." Extreme caution was probably not applied here. Jasper Reports create such a map when working with report parameters.

Following snippet from net.sf.jasperreports.engine.fill.JRFillDataset is probably the root cause, although there might be other as well: 

public void setParameterValues(Map<String,Object> parameterValues) throws JRException
{
parameterValues.put(JRParameter.REPORT_PARAMETERS_MAP, parameterValues);
...

Is there a good reason for doing this?