Code review request: 6973831 NPE when printing stack trace of OOME
mandy.chung at oracle.com
Thu Aug 12 11:29:03 PDT 2010
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
> 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?
> 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:
>>> 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).
More information about the core-libs-dev