Symptoms¶
You are getting the following error message...
When starting the Squish IDE
In the Squish IDE log file at
%appdata%\froglogic\Squish\workspace-ver-4\.metadata\.log
(Windows) or$HOME/.squish/workspace-ver-4/.metadata/.log
(Unix):
java.lang.OutOfMemoryError: Java heap space
This OutOfMemoryError is most of the time reported because the JVM (Java Virtual Machine) that executes the Squish IDE ran into its configured memory limit.
Possible solutions¶
Add heap space options to squishide.ini¶
Open squishide.ini <SQUISH_DIR>/bin/ide/squishide.ini
(Windows/Unix) or <SQUISH_DIR>/bin/ide/squishide.app/Contents/MacOS/squishide.ini
(Mac) in an editor and adjust (or append, if not there already) the lines...
...to...
So the complete file contents should look similar to this:
The parameter -Xmx specifies the maximum amount of heap size that the JVM of the Squish IDE is allowed to use. The value 768m
specifies 768 megabyte.
You may have to increase the -Xmx
parameter further if you still get the error.
Please note that specifying a value that is too large may cause failure to startup or falling back to the default heap size of currently 256 megabyte (or similar).
The value '2048' in this example is used for demonstration purpose only. The actual value should be adjusted to the capabilities of your hardware.
Too many log entries¶
Because the Squish IDE is Java application, and due to the nature of Java Virtual Machines having a fixed upper memory limit (for security reasons and resource conservation), anything that consumes resources in the Squish IDE can eventually contribute to its Java Virtual Machine running out of memory.
A typical cause is running whole test suites or many test cases which accumulate very large numbers of log entries.
Because of this memory configuration (and for other reasons, like not being able to choose the report format), the Squish IDE is not well equipped for such uses cases, and instead a batch file or shell script should be used to execute the desired test suites or test cases. (Also see Automated Batch Testing .)
Too many top level JavaScript classes, symbols¶
Too many top level JavaScript classes/symbols can cause severe increase of heap consumption (noticeable only starting at around a few hundred classes). For example:
Here is an example which avoids the large heap memory consumption by having only one top level class/symbol: