java.lang.StackOverflowError

[kneblix]

Hi

We were recently forced to switch to JRContinuationSubreportRunnerFactory. For some of our reports StackOverflowError is thrown. The same reports work perfectly fine with JRThreadSubreportRunnerFactory. We use jasperreports-3.0.0.-javaflow.jar, commons-javaflow-20060411.jar. Can't find the cause (nor solution) for this problem. Do you have any ideas?

Code:

Caused by: net.sf.jasperreports.engine.JRRuntimeException: java.lang.StackOverflowError    at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:635)    at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:344)    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:346)    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:305)    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillNoData(JRVerticalFiller.java:1540)    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:192)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:879)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:782)    at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:63)    at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:402)    at net.sf.jasperreports.engine.JasperFillManager.fillReportToStream(JasperFillManager.java:319)    at com.comp.cst.ejb.jasper.util.JasperUtil.generateReport(JasperUtil.java:305)    ... 66 moreCaused by: java.lang.StackOverflowError    at java.util.HashMap.newEntryIterator(HashMap.java:975)    at java.util.HashMap$EntrySet.iterator(HashMap.java:1080)    at java.util.AbstractMap.hashCode(AbstractMap.java:459)    at java.util.HashMap$Entry.hashCode(HashMap.java:848)    (... a lot of those ...)    at java.util.HashMap$Entry.hashCode(HashMap.java:848)    at java.util.AbstractMap.hashCode(AbstractMap.java:461)    at java.util.HashMap$Entry.hashCode(HashMap.java:848)    at java.util.AbstractMap.hashCode(AbstractMap.java:461)    at org.apache.commons.javaflow.utils.ReflectionUtils.getClassName(ReflectionUtils.java:160)    at org.apache.commons.javaflow.bytecode.Stack.pushObject(Stack.java:226)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:896)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:782)    at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:532)    at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:63)    at org.apache.commons.javaflow.bytecode.StackRecorder.execute(StackRecorder.java:95)    at org.apache.commons.javaflow.Continuation.continueWith(Continuation.java:170)    at org.apache.commons.javaflow.Continuation.startWith(Continuation.java:129)    at org.apache.commons.javaflow.Continuation.startWith(Continuation.java:102)    at net.sf.jasperreports.engine.fill.JRContinuationSubreportRunner.start(JRContinuationSubreportRunner.java:57)    at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:610)    at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:344)    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:348)    at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:305)    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillNoData(JRVerticalFiller.java:1540)    at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:192)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:879)    at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:782)    at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:63)    at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:402)    at net.sf.jasperreports.engine.JasperFillManager.fillReportToStream(JasperFillManager.java:319)    at com.comp.cst.ejb.jasper.util.JasperUtil.generateReport(JasperUtil.java:305)

Post Edited by kneblix at 09/22/2010 13:10

[rkm258]

Even i get the same stackoverflow error, only on one of our prod server. There is a bug logged in the tracker for this. I suggest u to add ur info there.

 

I found that for some reason when subreport doesn't fill in the remaining page and has to overflow, there is this error thrown, may be due to a deeply iterative logic. BUT it doesn't happen in one of our server, i have no reason for it. For now increasing your stack memory will be one option, but not a solution.

 

I prefer using javaflow over thread, to avoid creating multiple threads.

 

http://jasperforge.org/projects/jasperreports/tracker/view.php?id=4855

[lucianc]

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

[kneblix]

Thanks a lot, Lucian! Disabling debug logging works great so far.

[mhobijn]

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

[twoods]

 

Running Jasper Reports 4.0.1 using javaflow we are experiencing the exact same StackOverflowError and stack trace under the same condition of multi-page reports where sub-reports roll-over to another page, as posted by ceday on 1/7/2011 in issue tracker:
http://jasperforge.org/projects/jasperreports/tracker/view.php?id=5015
 

A few posted topics on this issue point back to this discussion as the solution by using a log4j.properties file containing this:
log4j.logger.org.apache.commons.javaflow=info

 

I have been experimenting with the placement of this log4j.properties file without success. The StackOverflow error happens in some environments and not others, and when it does happen it is consistent. I am not sold on the conclusion that the problem is a javaflow and logging problem, and am inclined to believe that the problem is something else that happens to be "covered up" by turning logging off. But I could be wrong and if there is more evidence to show that it is a logging problem and some more specific steps on exactly what to disable where then I am willing to try anything. ... I have some environments where I cannot make the problem occur including by trying to enable logging, so the problem is most elusive. We have tried various memory configuration parameters with no change. ... I have downloaded the javaflow source code (which is newer and out of sync with what is being distributed with even Jasper 4.1.1), to see if I can figure out what is really going on, but haven't made much progress yet.

In any case, this issue bothers us significantly. The Ultimate Guide 3 seems to argue the case for javaflow, but in reality how concerned should we be able running the threaded solution instead? Our offending report is a complex with potentially dozens of pages and 3 or 4 nested subreports, but 2 pages of it are enough to cause the StackOverflow.
 

Post Edited by twoods at 08/30/2011 02:42

[twoods]

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

[meatwad]

I've just run into this problem today so it still exists. I was able to use the workaround. How I did it was to create a

log4j.properties

file that includes this property:

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

Then I packaged it inside my war (I'm using a web application) under /WEB-INF/classes.

Has the real issue behind this error been discovered? I'm looking at putting JasperReports into production at my company but I'm very concerned about this.

[twoods]

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

[toffer]

I am gettting the same StackOverflowError Exception here, after switching to Javaflow. Unfortunately we needed to do this, as our application runs in a Weblogic container.

As I do not have a web-application and instead an ejb-ear and I am not certain where to place the mentioned log4j.properties. So far I tried META-INF/ and META-INF/classes/ but without any success.
Can anyone give an advice here? Or would it be possible to remove the "defective" part in Javaflow, as it is an open-source project?

Please help a very desperate developer :-(

 

 

[toffer]

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)[/code]

@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.

 

[toffer]

Although it seems I am the only one with the issue, not being able to change log4j's loglevel, I describe what I did to make it work for me.

• Checked out latest Javaflow code from here http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/
• Changed suspend() method's returntype to void ("so that's what the 'V' stands for after the NoSuchMethodError" :-)
• Commented out all log.debug() method calls
• Built and deployed it along with Jasperreport-Javaflow library

Hope that this might help someone with the same problem. Maybe someone will investigate what really causes the StackOverflowError...

 

[meatwad]

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?

[toffer]

see post below

[toffer]

In another project I found out, that you must put your .properties-files in a .jar-file and that must be inside the lib folder of your .ear.
--> someDeployment.ear/lib/someConfig.jar/someConfig.properties

Best way is to let Maven do this for you, although I would appreciate a more smarter approach.

[mareen]

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);...[/code]

Is there a good reason for doing this?

[sky.fion]

this fix problem http://jasperreports.sourceforge.net/maven2/commons-javaflow/commons-javaflow/20060411/

[quickdunk]

I have the same issue at JR621 version and can I fix the problem adding log4j.properties file to my app /WEB-INF/classes with a single line property:

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

After public the app with these modifications I restart the apache tomcat server and WORKS. Please don't forget this last step.