RFR [9] 8031050: [macosx] Crash while awt starting

Alan Bateman Alan.Bateman at oracle.com
Mon Feb 3 13:54:38 UTC 2014

On 03/02/2014 13:18, Chris Hegarty wrote:
> Hi,
> 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. 
> NPE.
> 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 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 


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 mailing list