This question already has answers here:
How to clear PermGen space Error in tomcat
(11 answers)
Closed 9 years ago.
I installed tomcat 7 to upgraded my JIRA projeect version from 5.0 to 6. After I place the project folder in tomcat's webapps. I run this localhost:8080/jira
after long time running, it throws some error message. Please help us to fix this problem thanks in advance
java.lang.RuntimeException: PermGen space
at com.atlassian.event.internal.SingleParameterMethodListenerInvoker.invoke(SingleParameterMethodListenerInvoker.java:54)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$2.run(AsynchronousAbleEventDispatcher.java:66)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher$1.execute(AsynchronousAbleEventDispatcher.java:32)
at com.atlassian.event.internal.AsynchronousAbleEventDispatcher.dispatch(AsynchronousAbleEventDispatcher.java:60)
at com.atlassian.event.internal.EventPublisherImpl.invokeListeners(EventPublisherImpl.java:160)
at com.atlassian.event.internal.EventPublisherImpl.publish(EventPublisherImpl.java:79)
at com.atlassian.plugin.event.impl.DefaultPluginEventManager.broadcast(DefaultPluginEventManager.java:84)
at com.atlassian.plugin.manager.DefaultPluginManager.addPlugins(DefaultPluginManager.java:768)
at com.atlassian.plugin.manager.DefaultPluginManager.init(DefaultPluginManager.java:200)
at com.atlassian.jira.plugin.JiraPluginManager.start(JiraPluginManager.java:63)
at com.atlassian.jira.ComponentManager$PluginSystem.start(ComponentManager.java:635)
at com.atlassian.jira.ComponentManager.startJIRA(ComponentManager.java:214)
at com.atlassian.jira.ComponentManager.quickStart(ComponentManager.java:208)
at com.atlassian.jira.ComponentManager.start(ComponentManager.java:193)
at com.atlassian.jira.upgrade.PluginSystemLauncher.start(PluginSystemLauncher.java:23)
at com.atlassian.jira.startup.DefaultJiraLauncher$3.run(DefaultJiraLauncher.java:107)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrEnqueue(DatabaseConfigurationManagerImpl.java:323)
at com.atlassian.jira.config.database.DatabaseConfigurationManagerImpl.doNowOrWhenDatabaseActivated(DatabaseConfigurationManagerImpl.java:211)
at com.atlassian.jira.startup.DefaultJiraLauncher.postDbLaunch(DefaultJiraLauncher.java:100)
at com.atlassian.jira.startup.DefaultJiraLauncher.access$100(DefaultJiraLauncher.java:27)
at com.atlassian.jira.startup.DefaultJiraLauncher$1.run(DefaultJiraLauncher.java:66)
at com.atlassian.jira.util.devspeed.JiraDevSpeedTimer.run(JiraDevSpeedTimer.java:33)
at com.atlassian.jira.startup.DefaultJiraLauncher.start(DefaultJiraLauncher.java:61)
at com.atlassian.jira.startup.LauncherContextListener.contextInitialized(LauncherContextListener.java:54)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4797)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5291)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.OutOfMemoryError: PermGen space
More helpful solution is to increase values in JAVA_OPTS variable.
Add next line to your Catalina.bat/Catalina.sh file in bin directory
For Windows (Catalina.bat)
set JAVA_OPTS="-Xms1024m -Xmx10246m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"
For Unix (Catalina.sh)
export JAVA_OPTS="-Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=356m -XX:PermSize=256m -XX:MaxPermSize=356m"
More solutions you can find in this article
Sometimes after re-deployments the Garbage Collector can't destroy some objects on Tomcat and run out of space.
There are many reasons for these case:
If you use some CRUD-Objects - check if there are all closed after using.
If your app used other libs - sometimes the Objects from these libs cant also be destroyed, like MysqlConnector, Hibernate/C3p0 or other - try to put these libs on the tomcat/lib folder
Check the Tomcat with the "Java VisualVM" and check the permGen after re-deployment.
The default value for the permGen Space are often also very low you can increase them with the following javaVM parameter
-XX:PermSize=64M -XX:MaxPermSize=256m
You can follow these tutorial
http://www.mkyong.com/tomcat/tomcat-javalangoutofmemoryerror-permgen-space/
UPDATE
other solution maybe found here : what to do with tomcat PermGen space
add -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC to the javaVM options
Tweak the value of the permgen using -XX:PermSize={value} and -XX:MaxPermSize={value} via the JAVA_OPTS variable where 'value' is a string like 256m.
Related
I am getting this java.lang.OutOfMemoryError: PermGen space Exception. I am using Eclipse Juno and Tomcat 7.0. This Exception occurs at least once in every 10-15 Minutes in a console. How to resolve it?
Feb 25, 2016 10:23:23 AM org.springframework.beans.factory.support.DefaultListableBeanFactory destroyBean
SEVERE: Destroy method on bean with name 'mvcUrlPathHelper' threw an exception
java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2895)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1173)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1681)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1559)
at org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor.postProcessBeforeDestruction(PersistenceAnnotationBeanPostProcessor.java:375)
at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:242)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:578)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:554)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:925)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:523)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingletons(DefaultListableBeanFactory.java:932)
at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:997)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:547)
Feb 25, 2016 10:23:24 AM org.springframework.beans.factory.support.DefaultListableBeanFactory destroyBean
SEVERE: Destroy method on bean with name 'mvcPathMatcher' threw an exception
java.lang.OutOfMemoryError: PermGen space
Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" java.lang.OutOfMemoryError: PermGen space
What is java.lang.OutOfMemoryError: PermGen space?
Ans:
The java.lang.OutOfMemoryError: PermGen space message indicates that the Permanent Generation’s area in memory is exhausted.
Any Java applications is allowed to use a limited amount of memory. The exact amount of memory your particular application can use is specified during application startup.
Java memory is separated into different regions which can be seen in the following image:
What will be the solution for this error PermGen space?
Ans:
For Heap,
export JVM_ARGS="-Xms1024m -Xmx1024m"
For Permgen,
JVM_ARGS="-XX:PermSize=512M -XX:MaxPermSize=512m"
You can give also additional section
-XX:MaxPermSize=512m -XX:+UseConcMarkSweepGC XX:+CMSClassUnloadingEnabled
You can also give more additional section :)
-XX:PermSize=512m -XX:MaxPermSize=512m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=128 -XX:TargetSurvivorRatio=90 -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:+UseTLAB -XX:+CMSParallelRemarkEnabled -XX:+CMSClassUnloadingEnabled
Metaspace: A new memory space is born
The JDK 8 HotSpot JVM is now using native memory for the representation of class metadata and is called Metaspace; similar to the Oracle JRockit and IBM JVM's.
The good news is that it means no more java.lang.OutOfMemoryError: PermGen space problems and no need for you to tune and monitor this memory space anymore.
Related Link:
https://plumbr.eu/outofmemoryerror/java-heap-space
https://plumbr.eu/outofmemoryerror/permgen-space
http://stas-blogspot.blogspot.in/2011/07/most-complete-list-of-xx-options-for.html#UseConcMarkSweepGC
https://www.javacodegeeks.com/2013/12/decoding-java-lang-outofmemoryerror-permgen-space.html
http://www.javavillage.in/reasons-outofmemory-permespace.php
Dealing with "java.lang.OutOfMemoryError: PermGen space" error
Java 8 Links
What is the use of MetaSpace in Java 8?
https://blogs.oracle.com/poonam/entry/about_g1_garbage_collector_permanent
https://plumbr.eu/outofmemoryerror/metaspace
https://dzone.com/articles/java-8-permgen-metaspace
It is easy to configure Java for more PermGenSpace but I would recommend to migrate to Java 1.8 runtime instead. Install Java 8 SDK and add two lines like
-vm
D:/jdk8/jre/bin/javaw.exe
to eclipse.ini. This problem is fixed starting from Java 1.8 and does not longer require any hacks.
Instead making changes in eclipse.ini, its better to install Java 8.
I Installed Java 8 and now I am not getting java.lang.OutOfMemoryError: PermGen space Exception.
I'm running a new Jeninks Master instance on Windows (windows server 2012).
The Jenkins master has failed twice in 5 days. the Jenkins instance has about 30 nodes and is not too busy.
I noticed the memory consumption of Jenkins was quite low (400mb) with the default java memory settings in jenkins.xml
I modified the jenkins.xml to -Xrs -Xmx1536m and the Java process is not using 515mb of memory.
I tried to set Xmx to a higher value but the Jenkins service would not start.
After the 2nd failure today, I got the same error message below repeated.
The windows server has 8 cores and 16GB memory. Average CPU is <5% and average memory usage is 2GB. Jenkins version is 1.609.3
Any help pointers appreciated....
Sep 21, 2015 12:00:48 PM org.eclipse.jetty.util.log.JavaUtilLog warn
WARNING:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.addWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
at winstone.BoundedExecutorService.scheduleNext(BoundedExecutorService.java:74)
at winstone.BoundedExecutorService.execute(BoundedExecutorService.java:64)
at org.eclipse.jetty.util.thread.ExecutorThreadPool.dispatch(ExecutorThreadPool.java:126)
at org.eclipse.jetty.server.nio.SelectChannelConnector$ConnectorSelectorManager.dispatch(SelectChannelConnector.java:300)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.dispatch(SelectChannelEndPoint.java:236)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.schedule(SelectChannelEndPoint.java:195)
at org.eclipse.jetty.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:498)
at org.eclipse.jetty.io.nio.SelectorManager$1.run(SelectorManager.java:290)
at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Found a solution to this. I installed the JDK and used VisualVM to monitor the memory usage for JVM. This showed 32 bit memory boundaries. After a little digging the java.exe that Jenins points to by default in Jenkins_Home/jre/bin is a 32bit version of java. I modified the Jenkins.xml to point to the already installed 64 Jre. This worked fine and was able to modify the Xmx valve to 4G. Jenkins is now running happly using <2gb of memory for the JVM process.
I am using Tomcat 7.0 And Windows Server OS 2008.
I am trying to upload 30 MB File when i try to read file then following error is generating.
I have 6 GB RAM and out of 6GB 2GB is free.
Caused by: java.lang.OutOfMemoryError: Java heap space
at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:41)
at java.awt.image.Raster.createPackedRaster(Raster.java:458)
at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
at java.awt.image.BufferedImage.<init>(BufferedImage.java:312)
at net.coobird.thumbnailator.util.BufferedImages.copy(Unknown Source)
at net.coobird.thumbnailator.tasks.io.OutputStreamImageSink.write(Unknown Source)
at net.coobird.thumbnailator.tasks.SourceSinkThumbnailTask.write(Unknown Source)
at net.coobird.thumbnailator.Thumbnailator.createThumbnail(Unknown Source)
at net.coobird.thumbnailator.Thumbnails$Builder.toOutputStream(Unknown Source)
at com.toocoolproductions.model.service.impl.UserSettingsServiceImpl.getScaledImage(UserSettingsServiceImpl.java:332)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
setavn.bat
if exist "%CATALINA_HOME%/jre1.6.0_20/win" (
if not "%JAVA_HOME%" == "" (
set JAVA_HOME=
)
set "JRE_HOME=%CATALINA_HOME%/jre1.6.0_20/win"
)
set "JAVA_OPTS=%JAVA_OPTS% -Dfile.encoding=UTF8 -Djava.net.preferIPv4Stack=true -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false -Duser.timezone=GMT -Xmx1024m -Xms1024M -XX:PermSize=256m -XX:MaxPermSize=256m"
echo %JAVA_OPTS%;
I try a lot after chages settings for -Xmx1024m -Xms1024M -XX:PermSize=256m -XX:MaxPermSize=256m for changes different-diffrent sizes but those are not working for me.
Please help me to solve this problem.
referer official issue:
java.lang.OutOfMemoryError: Java heap space when resize a specific image.
https://github.com/coobird/thumbnailator/issues/147
https://github.com/coobird/thumbnailator/wiki/Changes#outofmemoryerror-workaround
https://github.com/coobird/thumbnailator/issues/69
solution:
https://github.com/coobird/thumbnailator/wiki/Changes#outofmemoryerror-workaround
System.setProperty("thumbnailator.conserveMemoryWorkaround", "true");
i get the following error when i try to deploy a war (built with 'grails war') on a tomcat server. Unfortunately there is no other message in the logfile except this:
Nov 25, 2013 3:44:54 PM org.apache.tomcat.util.modeler.BaseModelMBean invoke
SEVERE: Exception invoking method check
java.lang.OutOfMemoryError: Java heap space
at java.io.DataInputStream.readUTF(DataInputStream.java:661)
at java.io.DataInputStream.readUTF(DataInputStream.java:564)
at org.apache.tomcat.util.bcel.classfile.ConstantUtf8.<init>(ConstantUtf8.java:47)
at org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:125)
at org.apache.tomcat.util.bcel.classfile.ConstantPool.<init>(ConstantPool.java:60)
at org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2118)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1994)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1960)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1945)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1319)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:976)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:541)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1461)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445)
How can i get more information about this error?
Notes:
the grails app is working locally without any issues
other grails apps are working on the same server without problems (all with version 2.2.0, the new one is on 2.3)
i already tried to extend the memory heap ... no improvement
Thank you
What Tomcat version you use? If you for example run Debian Wheezy box, the version available from packages is 7.0.28. It has some serious bugs about traversing classpaths for scanning for annotations (at least that's what I noticed after reading few other questions on SO and bug reports). I think it was fixed somewhere ~ 7.0.34. I had an exactly same problem and noticed that everything runs fine on newer versions.
1- Create setenv.sh in Tomcat(8||9)/bin/setenv.sh
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx2048m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxPermSize=256m"
2- chamod a+x setenv.sh
3- execute ./setenv.sh
4- ./startup.sh
Add to setenv.sh the following option in CATALINA_OPTS -XX:+HeapDumpOnOutOfMemoryError it will print heap dump when your deploy will fall down with OOM, which you can analyze by such utilities as JVisualVM or MemoryAnalyzer. After investigation of heap dump you can make decision:
Fix an issue which produce OutOfMemory
Increase heap size (by setting -Xmx in CATALINA_OPTS) in case you can't fix an issue.
Recently I started getting PermGen space issue in my new jasper report application when tested under heavy load. I'm using groovy as expression evaluator for reports, by specifying language="groovy in my jrxml file. As groovy expressions, create classes at runtime, I'm suspecting this to be the root cause for permgen filling up. I tried up setting up jvm options like -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled , but it did not help in solving the problem. Even in excpetion stacktrace (given below) also, classloader is trying to load the newly built class into permgen at the time of failure. Has anyone experienced this problem using groovy with jasper reports? My reports get filled asynchronously in a separate thread using capabalities provided by AsynchronousFillHandle class provided by jasper. Does this have any connection towards the classloader not releasing the loaded runtime classes? Any suggestions would be greatly appreciated.
Exception in thread "Thread-563" java.lang.OutOfMemoryError: PermGen space
Exception in thread "Thread-565" at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.define(ClassLoaderForClassArtifacts.java:42)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts$1.run(ClassLoaderForClassArtifacts.java:86)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts$1.run(ClassLoaderForClassArtifacts.java:84)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts.defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:84)
at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compilePogoMethod(CallSiteGenerator.java:215)
at org.codehaus.groovy.reflection.CachedMethod.createPogoMetaMethodSite(CachedMethod.java:220)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.createCachedMethodSite(PogoMetaMethodSite.java:206)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.createPogoMetaMethodSite(PogoMetaMethodSite.java:182)
at groovy.lang.MetaClassImpl.createPogoCallCurrentSite(MetaClassImpl.java:3034)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallCurrentSite(CallSiteArray.java:93)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at Section_1_1348126593121_343308.evaluate(calculator_Section_1_1348126593121_343308:253)
at net.sf.jasperreports.engine.fill.JREvaluator.evaluate(JREvaluator.java:190)
at net.sf.jasperreports.engine.fill.JRCalculator.evaluate(JRCalculator.java:591)
at net.sf.jasperreports.engine.fill.JRCalculator.evaluate(JRCalculator.java:559)
at net.sf.jasperreports.engine.fill.JRFillElement.evaluateExpression(JRFillElement.java:884)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:421)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:406)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:257)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:457)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2037)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:771)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportContent(JRVerticalFiller.java:301)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:148)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:909)
As a first bet...
Try to increase the perm gen size, like this:
-XX:MaxPermSize=128m
By default its 64m.
Hope this helps