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

[Coleen Phillimore]

Thank you for the suggestion for wording.  I'll change it to that.
Coleen

On 2/4/2011 12:05 AM, David Holmes wrote:
> 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
>>>>>
>>>
>>
>