Oracle Reports: Long running PDF Report crashes (rw.dll)

Target: Oracle Report should generate > 13000 pages of PDF output.
This is a long running report around 15 Minutes.
Is a Oracle report with paper layout.
Works perfect when pressing “run paper layout” in Oracle Reports Builder 10g (10.1.2.0.2)
Can scroll down to pag 13000.
Now I’d like to create a 13000 page pdf file.
Reports Developer Menu – FILE – GENERATE TO FILE – PDF
Report ist starting and counting up to something between 400 and 9000 pages – and then crashes.
The same behavior when doing it directly in Reports Developer as when depolyed on
OAS Reports Services.

Error Log :

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x65125621
Function=rwagrcm+0x51521
Library=C:\orant_10gR2\BIN\rw.dll

Current Java thread:
at oracle.reports.engine.EngineImpl.CRunReport(Native Method)
at oracle.reports.engine.EngineImpl.run(EngineImpl.java:437)
at oracle.reports.server.JobManager.runJobInEngine(JobManager.java:916)
– locked <0x11574a08> (a oracle.reports.engine.EngineImpl)
at oracle.reports.server.ExecAsynchJobThread.run(ExecAsynchJobThread.java:54)

…
…
…

Heap at VM Abort:
Heap
def new generation total 1344K, used 1227K [0x10030000, 0x101a0000, 0x113e0000)
eden space 1216K, 94% used [0x10030000, 0x1014fa78, 0x10160000)
from space 128K, 59% used [0x10160000, 0x101732c8, 0x10180000)
to space 128K, 0% used [0x10180000, 0x10180000, 0x101a0000)
tenured generation total 17012K, used 15998K [0x113e0000, 0x1247d000, 0x20030000)
the space 17012K, 94% used [0x113e0000, 0x1237fa28, 0x1237fc00, 0x1247d000)
compacting perm gen total 17408K, used 17308K [0x20030000, 0x21130000, 0x24030000)
the space 17408K, 99% used [0x20030000, 0x211173a8, 0x21117400, 0x21130000)

---

Solution 1:a) make the following change:
b) open the rwbuilder configuration file located in:

DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf

c) search for the following entry:

and replace the value=”50″ with a value that should be larger that the report output will be generated. (the value is in Mb)

d) restart the Reports Builder in order that the change will take effect .

---

Solution 2:a). locate the rwbuilder configuration file in:
DEVELOPER_SUITE_HOME\reports\conf\rwbuilder.conf and search for the
id=”rwEng” ../>tag.b). Add the following attributes to the engine tag:
jvmOptions=“-Xms1024m -Xmx1024m“for example
Change from

maxEngine=”1″ minEngine=”0″ engLife=”50″ maxIdle=”30″ callbackTimeOut=”60000″>

into

maxEngine=”1″ minEngine=”0″ engLife=”50″ maxIdle=”30″ callbackTimeOut=”60000″
jvmOptions=”-Xms512m -Xmx512m”>
This will set an Engine’s JVM options.

c). restart the report builder

( Alternate try to suppose this as a Oracle Reports command line extention as:
C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024m -XX:+PrintGCDetail” )

---

Solution 3:I think the problem is somewhere in the PermSize section of Java / JVM
I found an interesting link : http://forums.bea.com/bea/message.jspa?messageID=202465135&tstart=0 Afther that I started my report with:
C:\orant_10gR2\BIN\rwbuilder.exe jvmoptions=”-Xmx1024m -XX:+PrintGCDetail”
With this I tried getting more error information.
But what happend?
Beleve it or not. Now, my Report run successfully and created 13000 pdf pages.I will further investigate with jvmoptions:
-XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m

---

Additional information belonging to this Oracle Reports Bug (Java Problem, JVM):
I would bet you run out of permspace:
compacting perm gen total 9472K, used 9414K [0x30010000, 0x30950000, 0x34010000)
the space 9472K, 99% used [0x30010000, 0x30941a30, 0x30941c00, 0x30950000)I think low space is the problem, but I don’t know how to increase it… (I use the Eclipse platform)I solve the problem in desactivating the Hotspot mode with the option -Xint.The JVM options used are – maxpermsize 128M, xMs – 512M and xMx – 512M.The PERMANENT heap NEVER will reduce and in fact objects (Classes) placed in the PERMANENT heap are PERMANENTLY in that HEAP. Hence PERMANENT. No GC will ever unload any object from the permanent heap.When the perm gen is full, the classes would be unloaded from perm gen. And that is happening in my case also. The log file shows in some other cases when the perm gen size reaches some value of 46-47MB – the classes getting unloaded.

This is my currently VM options:
-Xms256m -Xmx256m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintGCApplicationStoppedTime -XX:NewSize=64M -XX:MaxNewSize=64M -XX:SurvivorRatio=8 -Xloggc:/logs/weblogic/jdevext/gc.log

The key parameters that you can send to the JVM are summarized below:
* -verbose:gc – Prints some GC info
* -XX:+PrintGCDetails – PrintGC details
* -XX:+PrintGCTimeStamps – Adds timestamp info to GC details
* -XX:+PrintHeapAtGC – Prints detailed GC info including heap occupancy before and after GC
* -XX:+PrintTenuringDistribution – Prints object aging or tenuring information
* -XX:+PrintHeapUsageOverTime – Print heap usage and capacity with timestamps
* -Xloggc:filename – Prints GC info to a log file

MaxPermSize ??
if Perm Size is in a separate area, are we saying that there should be a formula like: MaxNewSize+MaxPermSize=max heap size?
-ms512m -mx512m -XX:MaxPermSize=64m

Please try setting PermSize to the same value as MaxPermSize when you run the test.
-Xms512m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=64m

– The permanent space is memory allocated outside the regular heap (i.e. in addition to the -Xmx setting), so it is important to ensure there is enough physical RAM on the machine. The permanent space is used to primarily store classes and objects created for reflection support (methods etc.). If you have a large number of classes in a Java application, an OOM can occur if the PermSize is too small.
– For the Max. Heap size, what would you recommend trying? Setting MaxPermSize to 1/4 of Xmx is suffient??
– I’d suggest getting some data first using the -XX:+PrintGCDetails flag. This flag breaks down GC information into nursery, old and perm spaces. That should indicate which space is running out of memory. Note that setting this flag has a performance impact.
As a ballpark figure, I’d start with:
-Xms512m -Xmx512m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:PermSize=64m -XX:MaxPermSize=64m
Additional Links:
http://www.informit.com/guides/printerfriendly.asp?g=java&seqNum=99&rl=1
http://forum.java.sun.com/thread.jspa?tstart=0&forumID=27&threadID=343789&trange=15
http://forum.java.sun.com/thread.jspa?threadID=550279&messageID=2689390
http://forums.bea.com/bea/message.jspa?messageID=202464913&tstart=0
http://forums.oracle.com/forums/thread.jspa?messageID=453207