Request for review 6472925: OutOfMemoryError fails to generate stack trace as it now ought]

David Holmes David.Holmes at
Thu Feb 3 21:05:34 PST 2011

Hi Coleen,

Coleen Phillimore said the following on 02/04/11 14:28:
> Posted wrong webrev:
> open webrev at
> bug link at

Exactly what will appear on the error stream depends on where the
secondary exception occurs and on what the UncaughtExceptionHandler
actually does - it may not print at all. So the output here needs to be
standalone and not make any assumptions about what may or may not have
preceded it, so instead of:

       " - %s thrown from the UncaughtExceptionHandler\n",

I would suggest:

       "\nException: %s thrown from the UncaughtExceptionHandler in
thread %s\n",

The name of the thread is important for debugging.


> On 2/3/2011 11:17 PM, Coleen Phillimore wrote:
>> Okay, how about this:
>> Exception in thread "main" - java.lang.OutOfMemoryError thrown from 
>> the UncaughtExceptionHandler
>> And nothing new from jni_ExceptionDescribe.   See webrev:
>> local webrev at
>> local bug link
>> thanks,
>> Coleen
>> On 2/3/2011 8:15 PM, David Holmes wrote:
>>> Hi Coleen,
>>> I think there are two different cases here that need to be handled 
>>> differently, or at least the message printed needs to be different.
>>> jni_ExceptionDescribe is a JNI method that can be called by a thread 
>>> to do a stack dump of any currently pending exception. It is the 
>>> native equivalent of doing:
>>>    catch (Throwable t) {
>>>      t.printStackTrace();
>>>    }
>>> However, the method says nothing about the possibility of a secondary 
>>> exception occurring during this process - afterall this does not have 
>>> to be implemented using Java code, so exceptions (or not) are an 
>>> implementation artifact. Hence dropping the exception is not 
>>> unreasonable. But this is not uncaught-exception handling so I'm not 
>>> sure we should be reporting this secondary exception. If we do report 
>>> it then the message should provide some context:
>>> "jni_ExceptionDescribe encountered an internal exception: ..."
>>> Then for the actual uncaught-exception handler case:
>>> "Secondary exception thrown from the UncaughtExceptionHandler: ..."
>>> I think it would be confusing to report the same info in both cases 
>>> as they are very, very different.
>>> I also suspect that we may get complaints about "noise" here because 
>>> we may find that in some circumstances (such as when applets get 
>>> destroyed etc) that exceptions during uncaughtException handling are 
>>> common.
>>> David
>>> Coleen Phillimore said the following on 02/04/11 02:16:
>>>> Summary: Print an additional message for OOM during stack trace 
>>>> printing
>>>> ie:
>>>> Exception in thread "main" . Uncaught exception of type 
>>>> java.lang.OutOfMemoryError.
>>>> open webrev at
>>>> bug link at
>>>> thanks,
>>>> Coleen

More information about the hotspot-runtime-dev mailing list