Symptoms

Fisheye/Crucible crashes.

The following appears in the fisheye.out:

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 129944 bytes for Chunk::new
# An error report file with more information is saved as:
# /vol/fisheye.inst/hs_err_pid2608.log

Or:

fatal: Out of memory, malloc failed (tried to allocate 2463663235 bytes)

The hs_err_pid*.log generated will have the following error: 

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 77272 bytes for Chunk::new
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (allocation.cpp:328), pid=18733, tid=1199041424

Cause

This indicates that the Java Virtual Machine (JVM) has crashed because it is unable to obtain the necessary memory it requires from the operating system. The JVM will start up and attempt to reserve the minimum amount of memory as set in the Xms parameter which is usually 128mb. As Fisheye/Crucible requires more memory, it requests it from the JVM which will request it from the operating system. The available memory to Fisheye/Crucible (the heap size) will continue to expand up to the maximum memory allocation (Xmx). At any point the JVM can destroy objects in that memory using a process called Garbage Collection that will free up the memory. However, this crash typically comes from the JVM requesting memory from the OS and as the OS cannot provide it (as that memory may have been allocated elsewhere), so the JVM crashes, and Fisheye/Crucible is inaccesible.

Fisheye/Crucible can run for some time before this happens, as the heap will slowly expand until it hits a point where it's unable to retrieve that memory and then the process dies. For example, when running Fisheye/Crucible on a 32-bit OS the maximum available memory is only 1400mb. This consists of the maximum memory + PermGen + the JVM overhead (roughly 128mb). This gives a maximum of 1024 heap (Xmx) + 256 PermGen + 128 from the JVM (1408 total) for a Fisheye/Crucible instance. If there are other applications competing for that available memory on the same 32-bit OS it can cause this behaviour.

 Please see this Stackoverflow answer for further information on the memory limitations of Java in a 32-bit OS.

Workaround

1. Set the minimum and the maximum memory to the same amount (1024mb at most) as stated in Environment variables.
2. Restart Fisheye/Crucible.
3. If the problem persists, lower the minimum and maximum memory to 768mb, as if it's failing at 1024 it indicates the OS cannot provide sufficient memory.

Resolution

Upgrading to a 64-bit OS and 64-bit JDK will provide more available memory to a JVM and will resolve the problem.