Cryptic parsing error messages with `--link-at-build-time` and incomplete classpath

[zakkak]

Describe the issue
Parsing errors may be cryptic when using --link-at-build-time and incomplete classpath.
For instance if a Class A cannot be initialized due to a NoClassDefFoundError caused by a missing dependency, the user will be presented with an UnresolvedElementException stating that some method of Class A is unresolved, but it won't provide any additional info on the cause.

Steps to reproduce the issue

cd /tmp
git clone --branch 2023-03-21-graal-4661-parsing-error https://github.com/zakkak/issue-reproducers reproducer
cd reproducer
mvn package
export JAVA_HOME=/path/to/graalvm
# Attempt to generate native-image
$JAVA_HOME/bin/native-image \
  --no-fallback \
  -H:+ReportExceptionStackTraces \
  --link-at-build-time \
  --initialize-at-build-time=. \
  -jar target/reproducer-1.0-SNAPSHOT.jar

Describe GraalVM and your environment:

• GraalVM version (latest snapshot builds can be found here), or commit id if built from source: e9893c0
• JDK major version: 20
• OS: Fedora 37
• Architecture: AMD64

More details

The reproducer will result in build errors like the following:

Error: Unsupported features in 2 methods
Detailed message:
Error: Discovered unresolved method during parsing: net.sf.oval.expression.ExpressionLanguageJavaScriptImpl.<init>(). This error is reported at image build time because class net.sf.oval.expression.ExpressionLanguageRegistry is registered for linking at image build time by command line.
Error encountered while parsing net.sf.oval.expression.ExpressionLanguageRegistry.getExpressionLanguage(ExpressionLanguageRegistry.java:78) 
Parsing context:
   at net.sf.oval.AbstractCheck.isActive(AbstractCheck.java:151)
   at net.sf.oval.Validator.checkConstraint(Validator.java:763)
   at net.sf.oval.Validator._validateStaticInvariants(Validator.java:670)
   at net.sf.oval.Validator.validateInvariants(Validator.java:1382)
   at net.sf.oval.Validator.validate(Validator.java:1308)
   at gdv.xport.feld.Feld.validateInvariants(Feld.java:623)
   at gdv.xport.feld.Feld.validate(Feld.java:605)
   at gdv.xport.feld.AlphaNumFeld.validate(AlphaNumFeld.java:161)
   at gdv.xport.feld.Feld.validate(Feld.java:601)
   at gdv.xport.feld.Satznummer.validate(Satznummer.java:232)
   at gdv.xport.feld.Feld.isValid(Feld.java:583)
   at gdv.xport.feld.Feld.isInvalid(Feld.java:592)
   at gdv.xport.satz.Teildatensatz.getSatznummer(Teildatensatz.java:146)
   at gdv.xport.satz.Teildatensatz.toShortString(Teildatensatz.java:589)
   at gdv.xport.satz.Teildatensatz.findFeld(Teildatensatz.java:352)
   at gdv.xport.satz.Teildatensatz.getFeld(Teildatensatz.java:343)
   at gdv.xport.satz.Satz.findFeld(Satz.java:620)
   at gdv.xport.satz.Satz.getFeld(Satz.java:614)
   at gdv.xport.satz.Vorsatz.getErstellungsZeitraumBis(Vorsatz.java:229)
   at gdv.xport.satz.Vorsatz.setErstellungsZeitraumVon(Vorsatz.java:214)
   at gdv.xport.Datenpaket.setErstellungsDatumVon(Datenpaket.java:592)
   at gdv.xport.Datenpaket.<init>(Datenpaket.java:75)
   at gdv.xport.Datenpaket.<init>(Datenpaket.java:62)
   at Main.main(Main.java:5)
   at static root method.(Unknown Source)
...

not providing any indication about the reason the said method is unresolved (in this case the absence of org/mozilla/javascript/Scriptable from the classpath.

#6245 was meant to address this but it looks like there are cases that still escape.

The issue seems to be caused when Graal ignores NoClassDefFoundErrors in

graal/substratevm/src/com.oracle.svm.hosted/src/com/oracle/svm/hosted/phases/SharedGraphBuilderPhase.java

Lines 223 to 228 in e9893c0

	if (e.getCause() instanceof LinkageError || e.getCause() instanceof IllegalAccessError) {
	/*
	* Ignore LinkageError if thrown from eager resolution attempt. This is usually
	* followed by a call to ConstantPool.lookupType() which should return an
	* UnresolvedJavaType which we know how to deal with.
	*/

this results in the eager resolution failure to not get logged as the cause of the UnresolvedElement.

cc @cstancu

[knuspertante]

Hey @zakkak

I'm back in this game... Unfortunately since I updated some dependencies and restructure my project I'm no longer able to build it with native-image.

I use the same dependency (gdv.xport at version 6.5.0 now). In a small example like your reproducer (https://github.com/zakkak/mandrel/tree/2023-04-27-fix-6253) all works fine but in a larger project like described in #5711 it fails.

To build your reproducer I changed the following things:

• add org.apache.commons as dependency

 <dependency>
                    <groupId>org.apache.commons</groupId>
                    <artifactId>commons-jexl3</artifactId>
                    <version>3.2.1</version>
                    <exclusions>
                        <exclusion>
                            <groupId>commons-logging</groupId>
                            <artifactId>commons-logging</artifactId>
                        </exclusion>
                    </exclusions>
                </dependency>

• build native image with --initialize-at-build-time=net.sf.oval.ogn.ObjectGraphNavigatorJXPathImpl\,
  net.sf.oval.expression\,org.apache.logging.log4j.util.OsgiServiceLocator

native-image \
  --no-fallback \
  -H:+ReportExceptionStackTraces \
  --link-at-build-time \
  --initialize-at-build-time=net.sf.oval.ogn.ObjectGraphNavigatorJXPathImpl\\,\
net.sf.oval.expression\\,org.apache.logging.log4j.util.OsgiServiceLocator \
  -jar target/reproducer-1.0-SNAPSHOT.jar

Errror message:

Caused by: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved method during parsing: gdv.xport.feld.Feld.getInhalt(). This error is reported at image build time because class de.j21p.pandora.core.adapter.input.InputGdvXport is registered for linking at image build time by command line
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.reportUnresolvedElement(SharedGraphBuilderPhase.java:298)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.handleUnresolvedMethod(SharedGraphBuilderPhase.java:288)
	at org.graalvm.nativeimage.builder/com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.handleUnresolvedInvoke(SharedGraphBuilderPhase.java:244)

Now I have some trouble... Is it possible to get your pr compiled on my machine? FYI: I didn't compile graalvm by myself for now. Or to get any other support by you?

[zakkak]

Hi @knuspertante for building GraalVM from source you may refer to https://github.com/oracle/graal/tree/master/vm#readme

In short:

git clone https://github.com/graalvm/mx
git clone https://github.com/zakkak/mandrel --branch 2023-04-27-fix-6253 graal
cd graal/vm
../../mx/mx fetch-jdk --java-distribution labsjdk-ce-17
export JAVA_HOME=...
../../mx/mx --env ni-ce build

[knuspertante]

Hi @knuspertante for building GraalVM from source you may refer to https://github.com/oracle/graal/tree/master/vm#readme

In short:

git clone https://github.com/graalvm/mx
git clone https://github.com/zakkak/mandrel --branch 2023-04-27-fix-6253 graal
cd graal/vm
../../mx/mx fetch-jdk --java-distribution labsjdk-ce-17
export JAVA_HOME=...
../../mx/mx --env ni-ce build

@zakkak thanks a lot! You are my hero ;-)

[zakkak]

As discussed in #6507 (comment)

The only real solution for this problem requires extensive JVMCI changes: we would need to preserve resolution and linking errors via JVMCI, where they are currently just ignored.