nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to fix ScriptContext.class in coreapi.jar (PermGen)

work_ph

Over the past weeks I have been struggling with the famous memory problem PermGen when I deployed my report to my Tomcat 5.2.23. After a few clicks in the report there is still always a similar error to the following: 
 
"Report generation failed. Cause: There are errors evaluating script "params["myParams"].value": PermGen space" 
 
Those errors always refer to PermGen which means there isn't enough memory to execute the report. 
If you google this problem and/or look for it in BIRT exchange, most of the time you are recommended to enlarge the memory in the Java Options. I did that with several different adjustments in my catalina.sh file - without success though... 
 
Example: 
JAVA_OPTS="$JAVA_OPTS -Xms256M -Xmx1024M -XX:MaxPermSize=256m -XX:PermSize=128m -XX:+AggressiveHeap" 
 
Links: 
 
<a class='bbc_url' href='http://www.samaxes.com/2007/10/classloader-leaks-and-permgen-space/'>Classloader leaks and PermGen space - samaxes</a> 
 
<a class='bbc_url' href='http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java'>Frank Kieviet : Weblog</a> 
 
<a class='bbc_url' href='http://blogs.sun.com/fkieviet/entry/how_to_fix_the_dreaded'>Frank Kieviet : Weblog</a> 
 
These articles on the PermGen Memory issue tell that extending the memory does't solve the problem but only delay it. The real problem is that still reachable classes are being piled in the heap memory and therefore are not collected by the Garbage Collector. 
 
Regarding this post <a class='bbc_url' href='https://www.blogger.com/comment.g?blogID=14521551&postID=222993167941327241'>https://www.blogger.com/comment.g?blogID=14521551&postID=222993167941327241</a> , it claims that the file "scriptContext.class" in the jar file "coreapi.jar" has to be fixed to avoid the heaping of the classes and to prevent a memory leak. But I dont know exactly what has to be done. Do you have any solution for that?? 
 
On my tomcat only BIRT Viewer with my report and a small login application for access control are running and it keeps breaking down because of memory reasons. 
 
Thank you very much in andvance 
 
Kind regards 
 
work_ph

Find more posts tagged with

Comments

JasonW

Can you open a bug with this message posted to it?

Jason

work_ph

Hi Jason,

thanks for your answer! I solved the problem and increasing the memory size in Java_Opts in the end really helped.

regards

work_ph

JasonW

How did you solve the problem?

work_ph

I kept adapting the file "catalina.sh" of my Tomcat version. But the test server is running on a windows platform which means I have to adapt the file "catalina.bat" instead.

Here is the line I added in the "catalina.bat":

set JAVA_OPTS=-Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M

After that adjustment it worked fine.

However, I am still interested in the fact that even after undeploying the BIRT viewer there are still many left over objects in the heap memory not collected by the GC. Is that normal?

thanks for your answer Jason!!

regards

work_ph

JasonW

I would like to get a bug started if you know of any BIRT objects being left after undeploying.

Jason