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

[David Holmes]

Hi Coleen,

Coleen Phillimore said the following on 02/04/11 14:28:
> Posted wrong webrev:
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/6472925_3/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925_3

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:

    jio_fprintf(defaultStream::error_stream(),
       " - %s thrown from the UncaughtExceptionHandler\n",
       Klass::cast(pending_exception()->klass())->external_name());

I would suggest:

   jio_fprintf(defaultStream::error_stream(),
       "\nException: %s thrown from the UncaughtExceptionHandler in
thread %s\n",
       Klass::cast(pending_exception()->klass())->external_name(),
       get_thread_name());

The name of the thread is important for debugging.

Thanks,
David

> 
> 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 http://jruntime.east.sun.com/~coleenp/webrev/6472925_3
>> local bug link http://monaco.sfbay.sun.com/detail.jsf?cr=6472925
>>
>> 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 http://cr.openjdk.java.net/~coleenp/6472925/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=6472925
>>>>
>>>> thanks,
>>>> Coleen
>>>>
>>
>