NCDFE on jdk.internal.reflect.SerializationConstructorAccessorImpl

David Holmes david.holmes at oracle.com
Thu Dec 15 22:10:40 UTC 2016


Hi Andrew,

I'm redirecting this to jigsaw-dev as it seems to be a modularity 
related problem.

Additional comment below ...

David

On 16/12/2016 7:48 AM, Andrew Guibert wrote:
>
>
> Hello all,
>
> I've been doing some experimentation with WebSphere Liberty on Java 9 and
> ran into a problem that I believe is specific to the hotspot 9 JVM.  I am
> using a Liberty image compiled with Java 7, and am trying to get the server
> running with Java 9 at runtime.  So far things are working with the IBM JDK
> I have access to, but with the openjdk builds the boot process fails
> immediately.
>
> When I try to boot Liberty with OpenJDK (here I used 9-ea+149) I get a
> NCDFE as indicated in the title (see end of message for full stack trace).
> I believe this same issue may have been reported by Jon Berg back in April
> [1] but it looks like he didn't follow up on his initial note when asked
> for more info.
>
> I've done some digging and I believe that this error was introduced when
> classes were moved from sun.reflect to jdk.internal.reflect [2],
> specifically when sun.reflect.MagicAccessorImpl was moved to
> jdk.internal.reflect.MagicAccessorImpl.  According to the javadoc of
> MagicAccessorImpl, there are special tolerences in the VM which allow
> MagicAccessorImpl and its subclasses to bypass verification, and the
> javadoc also warns not to change the name of MagicAccessorImpl without
> updating the corresponding VM code. Since this was just indicated in a
> class-level javadoc comment, it could have been easily missed. The
> MagicAccessorImpl javadoc references bug 4486457, but I have not been able
> to find this id number in any public bug repository.

No it isn't public. Basically when the code-generating reflection 
mechanism was introduced verification had to be bypassed because the 
generated code didn't obey the expected subclassing rules for protected 
access - hence MagicAccessor.

> Switching over the the VM codebase, as far as I can tell everything has
> been updated properly, except for a reference in systemDictionary.hpp [3]
> which refers to MagicAccessorImpl as reflect_MagicAccessorImpl.  I assume
> this should instead be jdk_internal_reflect_MagicAccessorImpl (and other
> class entries in the block of lines 145-151 also seem to be missing the
> "jdk_internal_" prefix).

No those are just variable names that get mapped to full symbolic names 
e.g.:

./share/vm/classfile/vmSymbols.hpp:  template(reflect_MagicAccessorImpl, 
                 "jdk/internal/reflect/MagicAccessorImpl")

David
-----

> I haven't been able to reproduce this error in a standalone test case.
> However, if anyone wants to see the error for themselves the issue can be
> reproduced with Liberty in a matter of minutes by downloading a Liberty
> zip, extracting it, and doing wlp/bin/server create myServer &&
> wlp/bin/server run myServer with jdk9 set as $JAVA_HOME in the environment.
>
> [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-April/004121.html
> [2] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8606d027b2c2
> [3]
> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/545ddc149651/src/share/vm/classfile/systemDictionary.hpp#l145
>
> And finally, here is the stack trace:
>
> [12/15/16, 12:50:41:368 CST] 00000010 LogService-8-com.ibm.ws.config
> E CWWKE0701E: FrameworkEvent ERROR Bundle:com.ibm.ws.config(id=8)
> org.osgi.framework.BundleException: Exception in
> com.ibm.ws.config.internal.WSConfigActivator.start() of bundle
> com.ibm.ws.config
>   at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator
> (BundleContextImpl.java:795)
>   at org.eclipse.osgi.internal.framework.BundleContextImpl.start
> (BundleContextImpl.java:724)
>   at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0
> (EquinoxBundle.java:932)
>   at org.eclipse.osgi.internal.framework.EquinoxBundle
> $EquinoxModule.startWorker(EquinoxBundle.java:309)
>   at org.eclipse.osgi.container.Module.doStart(Module.java:581)
>   at org.eclipse.osgi.container.Module.start(Module.java:449)
>   at org.eclipse.osgi.container.ModuleContainer
> $ContainerStartLevel.incStartLevel(ModuleContainer.java:1620)
>   at org.eclipse.osgi.container.ModuleContainer
> $ContainerStartLevel.incStartLevel(ModuleContainer.java:1600)
>   at org.eclipse.osgi.container.ModuleContainer
> $ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1571)
>   at org.eclipse.osgi.container.ModuleContainer
> $ContainerStartLevel.dispatchEvent(ModuleContainer.java:1514)
>   at org.eclipse.osgi.container.ModuleContainer
> $ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
>   at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent
> (EventManager.java:230)
>   at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run
> (EventManager.java:340)
> Caused by: java.lang.NoClassDefFoundError:
> jdk/internal/reflect/SerializationConstructorAccessorImpl
>   at java.base/jdk.internal.misc.Unsafe.defineClass0(Native Method)
>   at java.base/jdk.internal.misc.Unsafe.defineClass(Unsafe.java:1173)
>   at java.base/jdk.internal.reflect.ClassDefiner.defineClass
> (ClassDefiner.java:63)
>   at java.base/jdk.internal.reflect.MethodAccessorGenerator$1.run
> (MethodAccessorGenerator.java:400)
>   at java.base/jdk.internal.reflect.MethodAccessorGenerator$1.run
> (MethodAccessorGenerator.java:394)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at java.base/jdk.internal.reflect.MethodAccessorGenerator.generate
> (MethodAccessorGenerator.java:393)
>   at
> java.base/jdk.internal.reflect.MethodAccessorGenerator.generateSerializationConstructor
> (MethodAccessorGenerator.java:112)
>   at java.base/jdk.internal.reflect.ReflectionFactory.generateConstructor
> (ReflectionFactory.java:404)
>   at
> java.base/jdk.internal.reflect.ReflectionFactory.newConstructorForSerialization
> (ReflectionFactory.java:396)
>   at java.base/java.io.ObjectStreamClass.getSerializableConstructor
> (ObjectStreamClass.java:1416)
>   at java.base/java.io.ObjectStreamClass.access$1500
> (ObjectStreamClass.java:74)
>   at java.base/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:499)
>   at java.base/java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:474)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at java.base/java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:474)
>   at java.base/java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:371)
>   at java.base/java.io.ObjectOutputStream.writeObject0
> (ObjectOutputStream.java:1132)
>   at java.base/java.io.ObjectOutputStream.writeObject
> (ObjectOutputStream.java:348)
>   at
> com.ibm.ws.config.admin.internal.ConfigurationStore.serializeConfigurationData
> (ConfigurationStore.java:213)
>   at com.ibm.ws.config.admin.internal.ConfigurationStore$2.run
> (ConfigurationStore.java:123)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at com.ibm.ws.config.admin.internal.ConfigurationStore.saveConfiguration
> (ConfigurationStore.java:120)
>   at com.ibm.ws.config.admin.internal.ExtendedConfigurationImpl.updateCache
> (ExtendedConfigurationImpl.java:471)
>   at com.ibm.ws.config.xml.internal.ConfigUpdater.updateConfiguration
> (ConfigUpdater.java:266)
>   at com.ibm.ws.config.xml.internal.ConfigUpdater.updateConfiguration
> (ConfigUpdater.java:195)
>   at com.ibm.ws.config.xml.internal.ConfigUpdater.update
> (ConfigUpdater.java:110)
>   at com.ibm.ws.config.xml.internal.ConfigUpdater.update
> (ConfigUpdater.java:96)
>   at com.ibm.ws.config.xml.internal.ChangeHandler.updateAtStartup
> (ChangeHandler.java:381)
>   at com.ibm.ws.config.xml.internal.SystemConfiguration.start
> (SystemConfiguration.java:137)
>   at com.ibm.ws.config.xml.internal.WSConfigXMLActivator.start
> (WSConfigXMLActivator.java:108)
>   at com.ibm.ws.config.internal.WSConfigActivator.start
> (WSConfigActivator.java:38)
>   at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run
> (BundleContextImpl.java:774)
>   at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run
> (BundleContextImpl.java:1)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator
> (BundleContextImpl.java:767)
>   ... 12 more
> Caused by: java.lang.ClassNotFoundException:
> jdk.internal.reflect.SerializationConstructorAccessorImpl cannot be found
> by com.ibm.ws.config_1.0.16.20161111-1635
>   at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal
> (BundleLoader.java:461)
>   at org.eclipse.osgi.internal.loader.BundleLoader.findClass
> (BundleLoader.java:372)
>   at org.eclipse.osgi.internal.loader.BundleLoader.findClass
> (BundleLoader.java:364)
>   at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass
> (ModuleClassLoader.java:161)
>   at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
>   ... 48 more
>
>
> - Andy Guibert
>


More information about the jdk9-dev mailing list