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