I'am noticing this StackOverflow Error once in a while. Unable to know the real cause. It is getting hard to replicate as well. I'am using JasperReports Javaflow 3.7.2, in a Java Service Wrapper, called from Tomcat.

Any help will be appreciated. Attached is the report template and its subreport. Also attached is a sample pdf report.

Exception is thrown at :

jasperPrint = JasperFillManager.fillReport(jasperReport, parameters, session.connection()); // Hibernate Session is used.

I'am using 3 subreports, where one of it has an expression of the form

($P{boolean_includePointsColumn}.booleanValue()?new File($P{path} + "TranscriptWithPicture_SubReport.jasper"):new File($P{path} + "TranscriptWithPicture_NoPoints_SubReport.jasper"))

[INFO] 2010.07.02 11.11.50.817 | {com.dataart.spiral.middleware.MiddlewareImpl} LR: GenerateReportLR UID:null
[INFO] 2010.07.02 11.11.51.053 | {com.dataart.spiral.services.handlers.report.GenerateReportLRH} Exception: net.sf.jasperreports.engine.JRRuntimeException:
java.lang.StackOverflowError
 net.sf.jasperreports.engine.fill.JRFillSubreport#prepare[l: 710]
 net.sf.jasperreports.engine.fill.JRFillElementContainer#prepareElements[l: 329]
 net.sf.jasperreports.engine.fill.JRFillBand#fill[l: 419]
 net.sf.jasperreports.engine.fill.JRFillBand#fill[l: 378]
 net.sf.jasperreports.engine.fill.JRVerticalFiller#fillColumnBand[l: 2018]
 net.sf.jasperreports.engine.fill.JRVerticalFiller#fillDetail[l: 757]
 net.sf.jasperreports.engine.fill.JRVerticalFiller#fillReportStart[l: 269]
 net.sf.jasperreports.engine.fill.JRVerticalFiller#fillReport[l: 127]
 net.sf.jasperreports.engine.fill.JRBaseFiller#fill[l: 938]
 net.sf.jasperreports.engine.fill.JRBaseFiller#fill[l: 841]
 net.sf.jasperreports.engine.fill.JRFiller#fillReport[l: 58]
 net.sf.jasperreports.engine.JasperFillManager#fillReport[l: 417]
 com.dataart.spiral.services.handlers.report.GenerateReportLRH#handleRequest[l: 169]
 com.dataart.spiral.services.handlers.report.GenerateReportLRH#handleRequest[l: 42]
 com.dataart.spiral.services.lrc.HibernateLiteweightHandler#handleRequest[l: 43]
 com.dataart.spiral.middleware.MiddlewareImpl#processRequest[l: 274]
 sun.reflect.GeneratedMethodAccessor39#invoke[l: -1]
 sun.reflect.DelegatingMethodAccessorImpl#invoke[l: 25]
 java.lang.reflect.Method#invoke[l: 597]
 sun.rmi.server.UnicastServerRef#dispatch[l: 305]
 sun.rmi.transport.Transport$1#run[l: 159]
 java.security.AccessController#doPrivileged[l: -2]
 sun.rmi.transport.Transport#serviceCall[l: 155]
 sun.rmi.transport.tcp.TCPTransport#handleMessages[l: 535]
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler#run0[l: 790]
 sun.rmi.transport.tcp.TCPTransport$ConnectionHandler#run[l: 649]
 java.util.concurrent.ThreadPoolExecutor$Worker#runTask[l: 886]
 java.util.concurrent.ThreadPoolExecutor$Worker#run[l: 908]
 java.lang.Thread#run[l: 619]
cause:java.lang.StackOverflowError:
null
 java.util.HashMap$Entry#hashCode[l: 720]
 java.util.AbstractMap#hashCode[l: 461]
 java.util.HashMap$Entry#hashCode[l: 720]
 java.util.AbstractMap#hashCode[l: 461]
 java.util.HashMap$Entry#hashCode[l: 720]

   NOTE: THIS ABOVE HashMap LINE REPEATS AROUND SEVERAL HUNDREDS OF LINES
 

What would be relevant to see are stacktrace lines just before the HashMap loop starts, to see where the initial call to hashCode() is made from.

In any case, the problem is caused by the fact that JasperReports put the parameters map in itself, i.e. parametersMap.put(key, parametersMap).  This causes the loop when parametersMap.hashCode() is called.  Log this as a bug and we'll see what we can do about it.

Regards,

Lucian

rmukkamalla
Wrote:

SourceForge ID?  Where did you log the bug?  JR bugs should be logged using the trackers of this project.

Regards,

Lucian