Fix proposal: JDK-8219378 NPE in ReflectionFactory.newMethodAccessor when langReflectAccess not initialized

[Andrew Leonard]

Hi Mandy,
I must admit I don't completely follow the logic of the existing Modifier 
init of langReflectAccess, the comment indicates a "protocol between 
java.lang and java.lang.reflect". I can try moving the clinit code from 
Modifier to AccessibleObject, but I question is there some reason it is 
there? Would we be sure in moving it we are not missing something?
Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leonard at uk.ibm.com 




From:   Mandy Chung <mandy.chung at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>, Roger Riggs 
<Roger.Riggs at oracle.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   22/02/2019 18:17
Subject:        Re: Fix proposal: JDK-8219378 NPE in 
ReflectionFactory.newMethodAccessor when langReflectAccess not initialized



Hi Andrew,

Thanks for the stack trace of the issue triggering this.

It seems to me that Modifier::<clinit> isn't the right place
to setLangReflectAccess shared secret.  It might have assumed
that Modifier should have been initialized when Field/Method
or other AccessibleObject is instantiated which isn't true
since the modifiers field is an int.

While the fix looks okay, would you mind trying a different fix
moving Modifier::<clinit> to AccessibleObject?  See this resolves
the issue when running on J9?

Mandy

On 2/22/19 12:49 AM, Andrew Leonard wrote:
> Hi Roger,
> I had a think about this and a testcase will be difficult, as it was 
found
> during OpenJ9 testing and occured during VM bootstrap, feel free to read
> further details here:
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9_issues_3399-23issuecomment-2D459004840&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=a83hTiGAixSJXbKXDa5xzF-Z_N-iYoFk9QcOrQ3Zgiw&s=nI8avX9tV8iOOqNvlUPGi6avSq5-h2fXeHvlzjFHeBY&e=

> So the issue was discovered due to the bootstrap behaviour, it was not
> observed with Hotspot, however given the obvious missing initialization
> check logic in the class it's not to say there's an untested route with
> Hotspot that could hit it... I'm not sure how I could scaffold a jtreg
> test to replicate the same?
> Thanks
> Andrew




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU