Quarkus' DiagnosticPrinter incompatible with GraalVM / Mandrel 22.1-dev

[zakkak]

Describe the bug

A recent GraalVM refactoring moved com.oracle.svm.core.posix.thread.PosixJavaThreads#getPthreadIdentifier and com.oracle.svm.core.posix.thread.PosixJavaThreads#hasThreadIdentifier to a new class com.oracle.svm.core.posix.thread.PosixPlatformJavaThreads making the following code to cause native-image failures since GraalVM fails to find the corresponding methods:

quarkus/core/runtime/src/main/java/io/quarkus/runtime/graal/DiagnosticPrinter.java

Lines 18 to 26 in 5036e2f

	@TargetClass(className = "com.oracle.svm.core.posix.thread.PosixJavaThreads")
	@Platforms({ Platform.LINUX.class, Platform.DARWIN.class })
	static final class Target_PosixJavaThreads {
	@Alias
	static native Pthread.pthread_t getPthreadIdentifier(Thread thread);
	@Alias
	static native boolean hasThreadIdentifier(Thread thread);
	}

Expected behavior

Quarkus should work with the upcoming 22.1 GraalVM release

Actual behavior

Quarkus fails with:

 Error: Could not find target method: static native com.oracle.svm.core.posix.headers.Pthread$pthread_t io.quarkus.runtime.graal.DiagnosticPrinter$Target_PosixJavaThreads.getPthreadIdentifier(java.lang.Thread)
com.oracle.svm.core.util.UserError$UserException: Could not find target method: static native com.oracle.svm.core.posix.headers.Pthread$pthread_t io.quarkus.runtime.graal.DiagnosticPrinter$Target_PosixJavaThreads.getPthreadIdentifier(java.lang.Thread)
	at com.oracle.svm.core.util.UserError.abort(UserError.java:72)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.findOriginalMethod(AnnotationSubstitutionProcessor.java:764)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleMethodInAliasClass(AnnotationSubstitutionProcessor.java:381)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleAliasClass(AnnotationSubstitutionProcessor.java:353)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.handleClass(AnnotationSubstitutionProcessor.java:323)
	at com.oracle.svm.hosted.substitute.AnnotationSubstitutionProcessor.init(AnnotationSubstitutionProcessor.java:279)
	at com.oracle.svm.hosted.NativeImageGenerator.createAnnotationSubstitutionProcessor(NativeImageGenerator.java:923)
	at com.oracle.svm.hosted.NativeImageGenerator.setupNativeImage(NativeImageGenerator.java:836)
	at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:551)
	at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:511)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:423)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:598)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:128)
	at com.oracle.svm.hosted.NativeImageGeneratorRunner$JDK9Plus.main(NativeImageGeneratorRunner.java:628)

See https://github.com/graalvm/mandrel/runs/5103314555?check_suite_focus=true#step:11:177

How to Reproduce?

1. Download latest nightly build of GraalVM from https://github.com/graalvm/graalvm-ce-dev-builds/releases/
2. Try to create a native Quarkus application or integration test with it

Output of uname -a or ver

GH runner

Output of java -version

11.0.14 and 17.0.2

GraalVM version (if different from Java)

22.1.0-deva0db6e1

Quarkus version or git rev

8de3797

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)

Additional information

This issue is related to the discussion in oracle/graal#4146. DiagnosticsPrinter is relying on GraalVM internals, as a result it's expected for such code segments to cause issues from time to time.

The question is: Do Quarkus users and devs use the DiagnosticsPrinter? Is it worth performing version checks (and complicating things by not using public APIs) to make it work or is it something we could remove?

cc @geoand @gsmet @stuartwdouglas

[quarkus-bot]

/cc @Karm, @galderz

[gsmet]

Do we still need DiagnosticPrinter? /cc @stuartwdouglas

[geoand]

Do we still need DiagnosticPrinter?

I've been wondering the same for a while...

[stuartwdouglas]

I don't know, I don't use it. If people do actually use it then it seems like the sort of thing that you could put in a library rather than Quarkus core.

[geoand]

I propose we just remove it for starters...

[zakkak]

I don't know, I don't use it. If people do actually use it then it seems like the sort of thing that you could put in a library rather than Quarkus core.

That would still leave us with a dependency on GraalVM's internals, i.e. PosixJavaThreads.getPthreadIdentifier.

I propose we just remove it for starters...

I have created #23542 to resolve this issue without removing DiagnosticPrinter. We could probably add a deprecation note before completely removing it.

[maxandersen]

having ability to get thread dump in native is useful. is there another way to get that than DIagnosticPrinter?

[zakkak]

having ability to get thread dump in native is useful. is there another way to get that than DIagnosticPrinter?

You should be able to get the thread dump from gdb but it might not be as intuitive as the DiagnosticPrinter and it will also only work for native executables compiled with debuginfo enabled:

1. break program execution (either at a breakpoint or using Ctrl-C)
2. dump traces with thread apply all backtrace

or one at a time:

2. list threads with info threads
3. select thread with thread command, e.g. thread 2
4. print stack trace with backtrace

[galderz]

@zakkak Could you add that info the native reference guide? Maybe as an FAQ entry on how to get a thread dump?

[zakkak]

@zakkak Could you add that info the native reference guide? Maybe as an FAQ entry on how to get a thread dump?

Done: #23837