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 :
 customer  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) 
======================================================================
Posted Date : 2006-12-14 19:44:15.0

N/A

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.
  xxxxx@xxxxx   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. 
  xxxxx@xxxxx   2005-04-20 15:43:22 GMT
  xxxxx@xxxxx   2005-06-09 11:25:37 GMT

Fine i am also getting the similer kind of error, can any one 
give me some solution for this.

I would also love to be able to get a Stack Trace when an OutOfMemoryError occurs.  Honestly, it's pretty ridiculous that you can't do this.  I hope they fix this in 1.5.

The OutOfMemoryError object itself is pre-allocated so that it can be thrown -- obviously when you are out of memory the VM cannot allocate a new OutOfMemoryError object.  The VM could reseve space for a stack trace at the same time.  Pick an amount, any amount.  Even if I could only see the top 10/15 lines of the stack trace it would help a *lot*.

Can some one tell me which release this will be available? 

Thank you, thank you, thank you!  I had been banging my head against a wall for hours trying to figure out where the error was in my code with Java 1.5, but the trace in Java 1.6 made it a snap.  I'd strongly suggest backporting this to Java 1.5.1!