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

David Holmes David.Holmes at oracle.com
Thu Aug 12 01:26:26 UTC 2010


I'm a bit behind on this functionality as I have no ideas what a 
suppressed exception is. :) 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.

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
> 



More information about the core-libs-dev mailing list