Community
Participate
Working Groups
As described in bug 396016, exporting projects with the DB-Tool in the 32-bit version of the standalone does not work: Using the DBTool I was only able to export the ite project when using the 64bit-version. When trying to perform an export using the 32bit version I got the error message on windows "The JVM found at K:\guidancer\Workspace\hu_snapshot\current\platforms\win32.win3 2.x86\jre is damaged. Please reinstall or define EXE4J_JAVA_HOME to point to an installed 32-bit JDK or JRE. The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution." This also occurred when trying to export a smaller project like caa_javafx. Using the 64bit-version worked fine as expected.
I'm (at the moment) neither able to start the dbtool, nor the testexec (on the g8 for a 32-bit current installation), nor autrun, nor autagent, nor the ITE. The configuration though seems to be ok - the testexec is running with an Xmx of 1280m and the dbtool with 1024m (autrun does not use an explicit Xmx). Lowering the ITEs Xmx to e.g. 924m instead of 1024m lead to a startable ITE. My current guess is: this is a g8 configuration problem in combination with Javas contiguous memory allocation. All nightly regression tests using the 32-bit version run - as far as I know - without any problems.
It should now be possible to use the corresponding <launcherName>.vmoptions | <launcherName>.ini file to alter the default VM settings for a custom environment.
I am still able to reproduce the behavior described in comment 1 even after modifying the <launcherName>.vmoptions | <launcherName>.ini. I tried to export the ite project from the testweek DB on the G8 machine. I set the xmx down to 100m but was not able to execute the dbtool
I was able to export our ite project with the dbtool from the current built on 2014-04-08, which runs on 32bit. @OG: Maybe you once set a variable, like JAVA_HOME, or something similar which now messes up the locating of the correct jre.
Closing this ticket after having talked to the team. It seems like the fix works for all but me :-(
