FIO07-J. Do not assume infinite heap space

A Java OutofMemoryError occurs if infinite heap space is assumed, making the program crash. This error can be generated due to the following possible reasons:

• A memory leak
• An infinite loop
• The program requires more memory than is present by default in the heap
• Incorrect implementation of common data structures (hash tables, vectors, etc.)
• Unbound deserialization
• Upon writing a large number of objects to an ObjectOutputStream

Noncompliant Code Example (1)

This example places no upper bound on the memory space required due to which the program can easily exhaust the heap.

A heap error will be generated if the heap continues to be populated even if there is no space available.

public class ShowHeapError {

  Vector<String> names = new Vector<String>();
  String newName=null;
  InputStreamReader input = new InputStreamReader(System.in);
  BufferedReader reader = new BufferedReader(input);

  public void addNames(){
    do{
         //Adding unknown number of records to a list
         //the user can enter as much data as he wants and exhaust the heap
         System.out.print(" To quit, enter \"quit\"\nEnter record: ");
         try {
               newName = reader.readLine();
               if(!newName.equalsIgnoreCase("quit")){
                 //names are continued to be added without bothering about the size on the heap
                 names.addElement(newName);
               }
   	      } catch (IOException e) {
   			}
              System.out.println(newName);
      }while (!newName.equalsIgnoreCase("quit"));
    }

  public static void main(String[] args) {
    ShowHeapError demo = new ShowHeapError();
    demo.addNames();
  }
}

Compliant Solution (1)

If the objects or data structures are large enough to potentially cause heap exhaustion, the programmer must consider using databases instead, to ensure that records are written to the disk in a timely fashion. Hence, this structure will never outgrow the heap.

In the above example, the user can reuse a single long variable to store the input and write that value into a simple database containing a table User with a field userID along with any other required fields. This will prevent the heap from getting exhausted.

Noncompliant Code Example (2)

In this example, the program needs more memory on the heap than is available by default. In a server-class machine running either VM (client or server) with a parallel garbage collector, the default initial and maximum heap sizes are as follows for J2SE 6.0 [[Sun 06]]:

• initial heap size: larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum

• maximum heap size: smaller of 1/4th of the physical memory or 1GB

public class ShowHeapError {

  /*Assuming the heap size as 512mB (calculated as 1/4th of 2 GB RAM = 512mB)
   * Considering long values being entered (64 bits each, the max number of elements
   * would be 5122mB/64bits = 67108864)
   */
   Vector<Long> names = new Vector<Long>(67108865);
   long newID=0L;
   int count = 67108865;
   int i = 0;
   InputStreamReader input = new InputStreamReader(System.in);
   Scanner reader = new Scanner(input);

   public void addNames(){

     do{
         /* Adding unknown number of records to a list
     	  * the user can enter more number of IDs than what the heap can support and 
          * exhaust the heap. Assume that the record ID is a 64 bit long value
     	  */
      	  System.out.print(" To quit, enter -1\nEnter recordID: ");
       	  newID = reader.nextLong();
       	  //names are continued to be added without bothering about the size on the heap
       	  names.addElement(newID);
       	  System.out.println(newID);
       	  i++;

       }while (i<count || newID!=-1);
   }

   public static void main(String[] args) {
     ShowHeapError demo = new ShowHeapError();
     demo.addNames();
   }
}

Compliant Solution (2)

The OutOfMemoryError can be avoided by making sure that there are no infinite loops, memory leaks or unnecessary object retention. If memory requirements are known ahead of time, the heap size in Java can be tailored using the following runtime parameters [2]:

java -Xms<initial heap size> -Xmx<maximum heap size>

For example:

java -Xms128m -Xmx512m ShowHeapError

Here we have set the initial heap size to 128MB and the maximum heap size to 512MB.

This setting can be done either in the Java Control Panel or on the command line. It cannot be adjusted through the application itself.

Noncompliant Code Example (2)

According to [[API 06]], Class ObjectInputStream documentation:

ObjectOutputStream and ObjectInputStream can provide an application with persistent storage for graphs of objects when used with a FileOutputStream and FileInputStream respectively. ObjectInputStream is used to recover those objects previously serialized. Other uses include passing objects between hosts using a socket stream or for marshaling and unmarshaling arguments and parameters in a remote communication system.

By design, only the first time an object is written, does it gets reflected in the stream. Subsequent writes write a handle to the object into the stream. A table mapping the objects written to the stream to the corresponding handle is also maintained. Due to this handle, references that may not persist during normal runs of the program are also retained. This can cause an OutOfMemoryError when streams remain open for extended durations.

FileOutputStream fos = new FileOutputStream("data.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(new Date());
// ... 

Compliant Solution (3)

If heap related issues arise, it is recommended that ObjectOutputStream.reset method be called so that references to previously written objects may be garbage collected.

FileOutputStream fos = new FileOutputStream("data.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(new Date());
oos.reset();  // Reset the Object-Handle table to its initial state
// ... 

Risk Assessment

It is difficult to identify code that can lead to a heap exhaustion since static analysis tools are currently unable to pinpoint violations. The heap size may also differ in different machines.

In the case of the heap size being increased through the command line, the risk assessment would be as follows:

In the case of the database solution being used, the cost would increase to high due to the usage of a disk-based solution.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website

References

[[Sun 06]] Garbage Collection Ergonomics, "Default values for the Initial and Maximum heap size"
[[Sun 06]] Non Standard Options for java: The Java application launcher, "Syntax for increasing the heap size"
[[Sun 03]] Chapter 5: Tuning the Java Runtime System, Tuning the Java Heap
[[API 06]] Class ObjectInputStream and ObjectOutputStream
[[SDN 08]] Serialization FAQ
[[MITRE 09]] CWE ID 400 "Uncontrolled Resource Consumption (aka 'Resource Exhaustion')"

FIO06-J. Validate user input      07. Input Output (FIO)      FIO31-J. Create a copy of mutable inputs