JDK-4753347 : OutOfMemoryError - Stack Trace missing
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2002-09-25
  • Updated: 2007-01-19
  • Resolved: 2005-06-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u12Fixed 6 b34Fixed
Related Reports
Relates :  
Relates :  
Description
Name: gm110360			Date: 09/25/2002


FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Here is a stack trace from an OutOfMemoryError.

java.lang.OutOfMemoryError
	<<no stack trace available>>



EXPECTED VERSUS ACTUAL BEHAVIOR :
It should have the trace because trace is 1-line deep,
there is not a large memory requirement for that.

A way to do that is to allocate memory for say a 1024
bytes stack trace in case of memory error. Also developers
dont understand why sometimes the stack trace gets printed
and sometimes not in case of an OutOfMemory error.

I dont understand myself why such an error is so fatal, if
memory gets low, and the user tries to allocate a new byte
[], the system should check before trying to allocate if
memory is sufficient (I guess it does that) and then throw
an Error. In that case, the system should reserve some
memory (from the startup of VM) for stack trace.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.*;
import java.util.List.*;

public class Test
{
	private static final int RATIO = 20;
	public static void main(String[] args)
	{
		try
		{
			List list = new ArrayList();
			while (true)
			{
				iterate(list);
				//recurse(list);
				
			}
		}catch (Throwable thr)
		{
			thr.printStackTrace();
		}
	}
	
	private static void recurse(List list)
	{
		iterate(list);
		
		recurse(list);
	}
	
	private static void iterate(List list)
	{
		long free = Runtime.getRuntime().freeMemory();
			int newSize = (int)free/RATIO;
		//System.out.println(free+","+newSize+","+(free-newSize));
		byte[] bytes = new byte[newSize];
		list.add(bytes);
	}
	
}

You can try to iterate or recurse. If the RATIO is set correctly, you will get
an exception without trace:



---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Put debug statements around the code to locate where the
code failed. Hard to do for code that is provided as
package.
(Review ID: 164948) 
======================================================================

Comments
EVALUATION This doesn't seem hard and worth doing. Will look into doing it for mustang, and backporting to 1.5.1 if low risk and if time permits. Sorry it fell under the radar for 1.5.0. ###@###.### 2005-1-14 20:34:35 GMT For mustang b34 we have improved implementation so that we have a few errors with preallocated backtrace available. This means that the first few threads to throw OutOfMemoryError will have a backtrace. ###@###.### 2005-04-20 15:43:22 GMT ###@###.### 2005-06-09 11:25:37 GMT
14-01-2005