Graal: [native-image] NPE in ChainedSubstitutionProcessor.lookup

Created on 8 Feb 2019  路  7Comments  路  Source: oracle/graal

In a complex application that works fine with Java 8 on SVM, I have an issue when using Java 11.
The final error is a NullPointerException inSubstitutionProcessor$ChainedSubstitutionProcessor.lookup since the first lookup returns null in
`second.lookup(first.lookup(method))

FYI, first is an AnnotationSupport instance and declaringClass.getSubstitutionMethod(method) returns null for
declaringClass = AnnotationType<jdk.jfr.Relational$$ProxyImpl -> HotSpotType<Lcom/sun/proxy/$Proxy37;, resolved>>
and
method = HotSpotMethod<$Proxy37.<init>(InvocationHandler)>

bug native-image

Most helpful comment

The proper fix for this is in #1001

All 7 comments

@johanvos Java 11 support is currently under development. See also https://github.com/oracle/graal/issues/561.

Digging a bit deeper in this, the failure occurs when trying to get the <init> method of a declaringClass that is an annotation (isAnnotation(declaringClass) returns true).
However, <init> is not in the list of methods for the corresponding Subtitution. Only equals, toString, hashCode and annotationType are added as subsitutionMethods.

The declaringClass itself is AnnotationType<jdk.internal.vm.annotation.ReservedStackAccess$$ProxyImpl -> HotSpotType<Lcom/sun/proxy/jdk/proxy1/$Proxy118;, resolved>> (hence @ReservedStackAccess)

In PR #981 I added the constructors to the list of substitutions, and the error is gone now. I'm not sure though if the constructors were removed deliberately (and only methods were used to create substitutions)?

I don't see how the substitutions for the constructors could be necessary, because the annotation objects are created during image generation and not at run time. Your PR substitutes the constructor with an accessor method that returns a field value - that is clearly a wrong functionality, i.e., if the constructor would ever be called horrible things would happen.

I think we first need an investigation why the constructor is requested at all. Maybe we can fix the problem at that level. If we decide that a constructor is necessary, we can substitute it with a new AnnotationConstructor implementation, which just throws an exception in the generated graph. That way at least we have a clear and correct error message at run time instead of a major corruption of the heap.

The problem occurs with Proxy classes that are annotations and that have an
The should indeed not be implemented with an AnnotationAccessorMethod.

The explanation about the issue can be found here.

The proper fix for this is in #1001

Was this page helpful?
0 / 5 - 0 ratings