RFR  8031050: [macosx] Crash while awt starting
david.holmes at oracle.com
Tue Feb 4 06:11:25 UTC 2014
On 3/02/2014 11:54 PM, Alan Bateman wrote:
> On 03/02/2014 13:18, Chris Hegarty wrote:
>> An old issue has resurfaced because of a change in AWT. AWT, now, on
>> Mac OS X, attaches a system graphics thread to the running VM, using
>> JNI_AttachCurrentThread. This change can result in a NPE, if a
>> security manager is installed, and the security manager tries to print
>> the name of the current thread.
>> In this case, attaching a thread to the VM, the j.l.Thread
>> instance/oop is created by the VM in allocate_threadObj(), and then
>> its constructor is run. At this point almost everything has been
>> created for the thread, jni env, etc, so it can query currentThread()
>> to retrieve itself. (Note: this is unusual. Typically the thread
>> running the j.l.Thread constructor is not itself.) Since the
>> j.l.Thread oop was allocated directly by the VM, its fields, other
>> than those directly set by allocate_threadObj(), are not initialized.
>> The call out from Thread.init to the security manager is problematic
>> as the partially constructed thread can be retrieved through
>> Thread.currentThread. Some of our internal tests run into a problem
>> when the security manager tries to print the name of the thread, i.e.
>> Clearly there are other concerns of accessing a partially constructed
>> thread, not just the thread name, but it seems reasonable to simply
>> move the setting of the name to the beginning of the init() method.
>> I propose the following change for JDK 9, with the intention of backport
>> exactly to JDK 8. Long term this should be revisited in JDK 9.
> As a short term fix then this looks okay to me. An alternative might be
> for getName to return the empty String if called before the name is set.
I think the current fix is preferable as it returns the correct name
rather than just side-stepping the NPE.
> I assume that part of re-visiting later will be to update API docs
> (maybe JNI spec too) to allow for initialization on the "current thread"
> when attaching as it can't be guaranteed to be fully initialized at this
What API docs do you think need updating? The revisiting would be to try
and find a complete solution to this initialization problem.
Unfortunately it is a catch-22: only an attached java thread can execute
Java code; initialization of the Thread object during the attach has to
execute Java code. Some possible solutions are suggested in a linked CR,
but none of them are ideal.
> PS: We should probably change the bug synopsis to make it clearer what
> this issue is about now.
More information about the core-libs-dev