Page History

A Java OutofMemoryError occurs if infinite when the program attempts to use more heap space than is assumed, making the program crash. This error can be generated due to the following possible reasonsavailable. Among other causes, this error may result from the following:

• A memory leak (see MSC04-J. Do not leak memory)
• An infinite loop
• The program requires more memory than is present by default in the heapLimited amounts of default heap memory available
• Incorrect implementation of common data structures (hash tables, vectors, etc.and so on)
• Unbound Unbounded deserialization
• Upon writing Writing a large number of objects to an ObjectOutputStream (see SER10-J. Avoid memory and resource leaks during serialization)
• Creating a large number of threads.
• Uncompressing a file (see IDS04-J. Safely extract files from ZipInputStream)

Some of these causes are platform-dependent and difficult to anticipate. Others, such as reading data from a file, are fairly easy to anticipate. As a result, programs must not accept untrusted input in a manner that can cause the program to exhaust memory.

Noncompliant Code Example (

...

readLine())

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.noncompliant code example reads lines of text from a file and adds each one to a vector until a line with the word "quit" is encountered:

public class ShowHeapErrorReadNames {

  private Vector<String> names = new Vector<String>();
  private final InputStreamReader input;
  private final BufferedReader reader;

  public ReadNames(String newName=null;
 filename) throws IOException {
   InputStreamReader this.input = new InputStreamReaderFileReader(System.infilename);
   BufferedReader this.reader = new BufferedReader(input);
  }

  public void addNames() throws IOException {
    try do{
      String newName;
     //Adding unknown number of records to a listwhile (((newName = reader.readLine()) != null) &&
         //the user can enter as much data as he wants and exhaust the heap !(newName.equalsIgnoreCase("quit"))) {
        names.addElement(newName);
         System.out.printprintln(" To quit, enter \"quit\"\nEnter record: "adding " + newName);
      }
    } tryfinally {
      input.close();
    }
  }

  public static void main(String[] args) throws IOException {
    if newName(args.length != reader.readLine(1) {
      System.out.println("Arguments: [filename]");
      return;
    }
    ReadNames demo = new ReadNames(args[0]);
      if(!newName.equalsIgnoreCase("quit")){
                 //names are continued to be added without bothering about the size on the heap
         demo.addNames();
  }
}

The code places no upper bounds on the memory space required to execute the program. Consequently, the program can easily exhaust the available heap space in two ways. First, an attacker can supply arbitrarily many lines in the file, causing the vector to grow until memory is exhausted. Second, an attacker can simply supply an arbitrarily long line, causing the readLine() method to exhaust memory. According to the Java API documentation [API 2014], the BufferedReader.readLine() method

Reads a line of text. A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed.

Any code that uses this method is susceptible to a resource exhaustion attack because the user can enter a string of any length.

Compliant Solution (Limited File Size)

This compliant solution imposes a limit on the size of the file being read. The limit is set with the Files.size() method, which was introduced in Java SE 7. If the file is within the limit, we can assume the standard readLine() method will not exhaust memory, nor will memory be exhausted by the while loop.

class ReadNames {
  // ... Other methods and variables

  public static final int fileSizeLimit = 1000000;

  public ReadNames(String filename) throws IOException {
    long size = Files.size( Paths.get( filename));
    if (size > fileSizeLimit) {
      throw new IOException("File too large");
    } else if (size == 0L) {
      throw new names.addElement(newNameIOException("File size cannot be determined, possibly too large");
    }
    this.input = new FileReader(filename);
    this.reader = new BufferedReader(input);
  }
}

Compliant Solution (Limited Length Input)

This compliant solution imposes limits both on the length of each line and on the total number of items to add to the vector. (It does not depend on any Java SE 7 or later features.)

class ReadNames {
   	      } catch (IOException e) {
   			}
              System.out.println(newName// ... Other methods and variables

  public static String readLimitedLine(Reader reader, int limit) 
                                       throws IOException {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < limit; i++) {
      int c = reader.read();
      }while (!newName.equalsIgnoreCase("quit"));
if (c == -1) {
        return ((sb.length() > 0) ? sb.toString() : null);
      }

  public static void main(String[] args      if (((char) c == '\n') || ((char) c == '\r')) {
    ShowHeapError demo = new ShowHeapError(    break;
      }
      sb.append((char) c);
    demo.addNames}
    return sb.toString();
  }
}

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 \[[Garbage 06|AA. Java References#Garbage 06]\]:

  public static final int lineLengthLimit = 1024;
  public static final int lineCountLimit = 1000000;

  public void addNames() throws IOException {
    try {
      String newName;
      for (int i = 0; i < lineCountLimit; i++) {
        newName = readLimitedLine(reader, lineLengthLimit);
        if (newName == null || newName.equalsIgnoreCase("quit")) {
          break;
        }
        names.addElement(newName);
        System.out.println("adding " + newName);
      }
    } finally {
      input.close();
    }
  }

}

The readLimitedLine() method takes a numeric limit, indicating the total number of characters that may exist on one line. If a line contains more characters, the line is truncated, and the characters are returned on the next invocation. This prevents an attacker from exhausting memory by supplying input with no line breaks.

Noncompliant Code Example

In a server-class machine using a parallel garbage collector, the default initial and maximum heap sizes are as follows for Java SE 6 [Sun 2006]:

• Initial initial heap size: larger of 1/64th 64 of the machine's physical memory on the machine or some reasonable minimum.
• maximum Maximum heap size: smaller of 1/4th 4 of the physical memory or 1GB.

This noncompliant code example requires more memory on the heap than is available by default:

public class ShowHeapError {

  /* Assuming the heap size as 512mB 512 MB 
 * (calculated as 1/4th4 of 22GB GB RAM = 512mB512MB)
   * Considering long values being entered (64 bits each, 
 * the max number of elements
   * would be 5122mB512MB/64bits64 bits = 
 * 67108864)
 */
public class ReadNames {
  */
 // Accepts unknown number of records
  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() {
    try {
      do {
         //* Adding unknown number of records to a list
      	  *// theThe user can enter more number of IDs than what the heap can support and,
 
       // as a *result, exhaust the heap. Assume that the record ID
 is a 64 bit long value
  // is a 	64-bit long */value
      	  System.out.print("Enter recordID (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(newIDnames.addElement(newID);
        i++;
      } while (i < count || newID != -1);
    }   	  System.out.println(newID);finally {
       	  i++;

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

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

Compliant Solution

...

A simple compliant solution is to reduce the number of names to read:

Code Block
bgColor #ccccff
// ... int count = 10000000; // ...

Compliant Solution

The OutOfMemoryError can be avoided by ensuring the absence of infinite loops, memory leaks, and unnecessary object retention. When memory requirements are known ahead of time, the heap size can be tailored to fit the requirements using the following runtime parameters [Java 2006 Wiki MarkupThe {{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 \[[Java 06|AA. Java References#Java 06]\]:

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

For example:,

java -Xms128m -Xmx512m ShowHeapErrorReadNames

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

This setting These settings can be done changed either in using the Java Control Panel or on from the command line. It They cannot be adjusted through the application itself.

Noncompliant Code Example (2)

Wiki MarkupAccording to \[[API 06|AA. Java References#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

Risk Assessment

Assuming infinite heap space can result in denial of serviceIt 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.

Related Vulnerabilities

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

Other Languages

...

The Apache Geronimo bug described by GERONIMO-4224 results in an OutOfMemoryError exception thrown by the WebAccessLogViewer when the access log file size is too large.

Automated Detection

Related Guidelines

...

...

...

...

Bibliography

...

Image Added Image Added Image Added

References

\[[Garbage 06|AA. Java References#Garbage 06]\] [Garbage Collection Ergonomics|http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html ], "Default values for the Initial and Maximum heap size"
\[[Java 06|AA. Java References#Java 06]\] [java - the Java application launcher|http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html ], "Syntax for increasing the heap size"
\[[Sun 03|AA. Java References#Sun 03]\] Chapter 5: Tuning the Java Runtime System, [Tuning the Java Heap|http://docs.sun.com/source/817-2180-10/pt_chap5.html#wp57027] 
\[[API 06|AA. Java References#API 06]\] Class ObjectInputStream and ObjectOutputStream
\[[SDN 08|AA. Java References#SDN 08]\] [Serialization FAQ|http://java.sun.com/javase/technologies/core/basic/serializationFAQ.jsp] 
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 400|http://cwe.mitre.org/data/definitions/400.html] "Uncontrolled Resource Consumption (aka 'Resource Exhaustion')"

MSC34-J. Prevent against SQL Injection      07. Input Output (FIO)      FIO31-J. Defensively copy mutable inputs and mutable internal components