Java heap space error in Oxygen 8.1

Post by **angela** » Fri May 04, 2007 8:49 pm

I've been experiencing weird random issues with Oxygen 8.1 recently, that go away when I reboot. I was going to use the reinstall feature but repaired instead. Now I am getting a Java heap space error every time I try to debug my file.

The error directs me to update the -Xmx parameter in the oxygen.ini and oxygen.bat files, but the value for -Xmx in oxygen.ini is not a standard Java parameter: -Xmx40:32:700P.

I've updated the parameters to -Xmx1024m and -Xms1024m, but still receive the error.

Please advise.

Angela Williams

Post by **george** » Fri May 04, 2007 9:56 pm

Hi Angela,

The -Xmx40:32:700P value is interpreated by the launcher and means something like 32% from the available memory if that is between 40Mb and 700Mb, otherwise use 40Mb if 32% is less than that or 700Mb if 32% is larger than that.

Was the same scenario working before? Can you send or better point us to some files we can reproduce the problem with (you can eventually send the info on our support at oxygenxml dot com address)? If not, then maybe it will help if you describe what you are doing and let us know how much memory you have.

Best Regards,
George

Post by **angela** » Wed May 09, 2007 9:59 pm

I've upgraded to version 8.2 and I'm still getting the error. I've updated the settings in oxygen.bat to 'java -Xmx1024m -Xms1024m' and oxygen.ini to 'Virtual Machine Parameters=-Xmx1024m -Xms512m'

My xml file is 3760 lines of code, 156kb. I have 2 gig of ram, Oxygen uses 1 gig and then stalls out, leaving me only around 400m of available ram. The error I'm trying to debug is an FO error, column-number can't be "".

I can't even view the output so I can determine where the error occurs, because the Oxygen error window keeps popping up so I can't get focus back on Oxygen. I have to kill it through Task Manager.

If I comment out most of the xml and just debug a small chunk at a time, I have no problems. I have also been able to debug this file successfully before with no issues.

Please advise - thanks!
Angela Williams

Post by **sorin_ristache** » Thu May 10, 2007 10:23 am

Hello,

Please give us more details about your computer: the Windows version, the version of the Java virtual machine. Also it will be useful to have the file which gives the error and to know a sequence of steps for reproducing the problem. You can send the file to our support address.

Regards,
Sorin

Post by **angela** » Thu May 10, 2007 4:30 pm

Windows XP Version 5.1 Build 2600.xpsp.050622-1524 Service pack 2. Java 1.5.0x

I can't give you my file, sorry. The xml file contains confidential information and I don't have the time to create a mock up of the same size. Also, I have over 20,000 lines of xsl transforming it - I can't send you all of that.

Once I fixed the single minor problem of having the column-number set on a table-cell being null, I was able to run the file in the debugger. I ran diagnostics against it - no infinite loops or infinite recursion - no one piece of code that took more than 1% of the processing time.

Post by **angela** » Thu May 10, 2007 4:32 pm

The sequence of steps is very basic....

Run a xslt transformation in the debugger on a file that has a null value for fo:table-cell. No breakpoints, no special processing. Using Saxon8b, XEP 4.4, xslt 2.0, xpath 2.0.

Post by **sorin_ristache** » Thu May 10, 2007 5:37 pm

You say that a modified version of a file in which the column-number set on a table-cell is null does not give the out of memory error. I think the error was caused by some code which was removed in the modified version. Without a sample file for reproducing the error we cannot find the cause of the error.

I hope this helps,
Sorin

Post by **angela** » Wed Sep 26, 2007 8:21 pm

Trying to run XEP from the command line gives me the same error. The fo is valid.

Post by **sorin_ristache** » Thu Sep 27, 2007 10:10 am

Hello,

You can try to set a large value for the maximum heap memory in the XEP command line using the -Xmx parameter, for example -Xmx1024m. This can avoid the out of memory error.

Regards,
Sorin