RFR 8079784: Unexpected IllegalAccessError when trying access InnerClasses attribute (original) (raw)

dean.long at oracle.com dean.long at oracle.com
Wed Oct 10 17:27:48 UTC 2018

On 10/10/18 5:35 AM, David Holmes wrote:

On 10/10/2018 9:48 PM, Harold David Seigel wrote:

Hi David,

Thanks for the review! Please see comments inline.

On 10/9/2018 9:35 PM, David Holmes wrote: Hi Harold, Looks fine as-is I have one query below ... One additional nit in jasm file - this purported line of source code is not correct:  60 //         Class<?> clazz = Buggered.Foo.class; as you aren't using that class. The test program was originally called Buggered.  I changed the name when creating the JTReg test but forgot to update the comment.  I'll fix it before pushing. On 10/10/2018 12:12 AM, Harold David Seigel wrote: Hi,

Please review this fix, proposed by Doug Simon, for JDK-8079784. The fix prevents classes in the InnerClasses attribute from being loaded unless they are actually being accessed. That in itself seems reasonable. I'm surprised we don't do more sanity checking on the classes listed in the inner classes attribute - I would have expected at least a "same package" check. Looking at the code itself: if (innerismember && ioff != 0 && ooff != 0) { +       if (cp->klassnameatmatches(outer, ooff) && +           cp->klassnameatmatches(inner, ioff)) { Klass* o = cp->klassat(ooff, CHECK); if (o == outer) { Klass* i = cp->klassat(ioff, CHECK); if (i == inner) { return; } } } +     } I'm wondering how it is possible to have the names match and yet potentially o!=outer and i!=inner ? Just guessing here but klassat() resolves the class. So potentially it could resolve to a different class with the same name. Yes but how could that be possible? How did you pass in a reference to a class with a given name which must recognizable by that name within the current classloader, yet when you resolve the CP entry - still in the current classloader - you somehow get a different class?

Do we necessarily know that inner's defining classloader is the same as outer's defining classloader here?  It seems like they could be different if outer's classloader is not well-behaved.  Even so, loader constraints should make sure that outer and inner resolve the names Outer and Outer$Inner to the same klasses, respectively, right?

dl

I had a similar check in the nestmates code and it was considered impossible and so removed.

Cheers, David

Also, while looking into this issue, I noticed that method issamepackagemember() is not used. So, I removed it as part of this webrev. In 8u it's called by Reflection::issamepackagemember, which in turn is unused. That was removed in 9 by the cleanup done in JDK-8140485. :) Hopefully, it's gone for good now. Thanks! Harold Thanks, David

Open Webrev: http://cr.openjdk.java.net/~hseigel/bug8079784/webrev/ JBS Bug:  https://bugs.openjdk.java.net/browse/JDK-8079784 The fix was tested with the test in the webrev and by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, running tiers 3-5 tests on Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. Thanks, Harold

More information about the hotspot-runtime-dev mailing list