Code review request: 6973831 NPE when printing stack trace of OOME

[Mandy Chung]

  On 08/11/10 18:26, David Holmes wrote:
> I'm a bit behind on this functionality as I have no ideas what a 
> suppressed exception is. :) 

FWIW.  The suppressed exceptions are added for automatic resource 
management (6911258).
    
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html

> That aside I'm curious as to the expected multi-thread usage for an 
> exception that requires these things to be thread-safe ? Given an 
> exception occurs in a given thread, passing it to another thread 
> should require some form of safe-publication.
>

Agree.  May I count you as a reviewer?
    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/

Thanks
Mandy

> David
>
> Mandy Chung said the following on 08/12/10 07:57:
>>  On 08/11/10 14:43, Mandy Chung wrote:
>>>  On 08/11/10 14:03, Rémi Forax wrote:
>>>> Brian, Mandy,
>>>> It seems this is not the sole thread-safety issue,
>>>> access to fields 'cause' or 'stackTrace' aren't thread safe too and 
>>>> detailMessage is not final.
>>>>
>>>
>>> I agree that the getCause and setStackTrace method need to be 
>>> synchronized.  On the other hand, the initCause and setStackTrace 
>>> methods are used to override the values initialized in the 
>>> constructor and so access to these fields are likely safe in 
>>> practice.  I can fix it as part of this fix.
>>>
>>
>> Fixed the getCause and setStackTrace methods:
>>    http://cr.openjdk.java.net/~mchung/6973831/webrev.02/
>>
>> Mandy
>>
>>> The "detailMessage" is not final because the VM in fact preallocates 
>>> Throwable object (OOME and ArithmeticException) and then sets the 
>>> 'detailMessage' field directly (as the constructor is not invoked).
>>>
>>> Mandy
>>