Quarkus: UnsupportedFeatureError: The offset of private final java.util.Set

[Sanne]

Describe the bug
The native image succeeds to build, but fails at startup:

N.B. the output seems partially corrupted as well?

[INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 83658ms
[INFO] 
[INFO] --- maven-failsafe-plugin:2.22.1:integration-test (default) @ quarkus-integration-test-jpa-h2 ---
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running io.quarkus.it.jpa.h2.JPAFunctionalityInGraalITCase
[INFO] H2 database started in TCP server mode; server status: TCP server running at tcp://192.168.1.218:9092 (only local connections)
Executing [/home/sanne/sources/quarkus/integration-tests/jpa-h2/target/quarkus-integration-test-jpa-h2-999-SNAPSHOT-runner, -Dquarkus.http.port=8081, -Dtest.url=http://localhost:8081, -Dquarkus.log.file.path=target/quarkus.log]
2020-02-06 13:44:35,565 ERROR [io.qua.application] (main) Failed to start application: com.oracle.svException in thread "main" java.lang.RuntimeException: Failed to start quarkus
    at io.quarkus.runnerm.core.jdk.UnsupportedFeatureError: The offset of private final java.util.Set sun.nio.ch.SelectorImp.ApplicationImpl.doStart(ApplicationImpl.zig:304)
    at io.quarkus.runtime.Application.start(Application.java:89)
    at io.quarkus.runtime.Application.run(Application.java:226)
    at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:41)
Caused by: com.oracle.svm.core.jdk.UnsupportedFeatureError: The offset of private final java.util.Set sun.nio.ch.SelectorImpl.selectedKeys is accessed without the field being first registered as unsafe accessed. Please register the field as unsafe accessed. You can do so with a reflection configuration that contains an entry for the field with the attribute "allowUnsafeAccess": true. Such a configuration file can be generated for you. Read CONFIGURE.md and REFl.selectedKeys is accessed without the field being first registered as unsafe accessed. Please regisLECTION.md for details.
    at com.oracle.svm.core.util.VMError.unsupportedFeature(VMError.java:101)
    at jdk.internal.misc.Unsafe.objectFieldOffset(Unsafe.java:50)
    at sun.misc.Unsafe.objectFieldOffset(Uter the field as unsafe accessed. You can do so with a reflection configuration that contains an entnsafe.java:640)
    at io.netty.util.internal.PlatformDependent0.objectFieldOffset(PlatformDependent0.java:505)
    at io.netty.util.internal.PlatformDependent.objectFieldOffset(PlatformDependent.java:651)
    at io.netty.channel.nio.NioEventLoop$4.run(NioEventLoop.java:219)
    at java.security.AccessController.doPrivileged(AccessController.java:81)
    at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:209)
    at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:142)
    at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:146)
    at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:37)
    at io.netty.util.concurrent.MultithreadEventExecutorGroupry for the field with the attribute "allowUnsafeAccess": true. Such a configuration file can be gene.<init>(MultithreadEventExecutorGroup.java:84)
    at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:58)
    at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:47)
    at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:59)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:86)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:81)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:68)
    at io.vertx.core.net.impl.transport.Transport.eventLoopGroup(Transport.java:153)
    at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:143)
    at io.vertx.core.impl.VertxImpl.vertx(VertxImpl.java:92)
    at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:40)
    at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:32)
    at io.vertx.core.Vertx.vertx(Vertx.java:85)
    at io.quarkus.vertx.core.runtime.VertxCoreRecorder.initializeWeb(VertxCoreRecorder.java:106)
    at io.quarkus.vertx.core.runtime.VertxCoreRecorder.initializeWeb(VertxCoreRecorder.java:88)
    at io.quarkus.deployment.steps.VertxCoreProcessor$buildWeb41.deploy_0(VertxCoreProcessor$buildWeb41.zig:88)
    at io.quarkus.deployment.steps.VertxCoreProcessor$buildWeb41.deploy(VertxCoreProcessor$buildWeb41.zig:36)
    at io.quarkus.runner.Applicatirated for you. Read CONFIGURE.md and REFLECTION.md for details.
    at com.oracle.svm.core.util.VMErroronImpl.doStart(ApplicationImpl.zig:186)
    ... 3 more
.unsupportedFeature(VMError.java:101)
    at jdk.internal.misc.Unsafe.objectFieldOffset(Unsafe.java:50)
    at sun.misc.Unsafe.objectFieldOffset(Unsafe.java:640)
    at io.netty.util.internal.PlatformDependent0.objectFieldOffset(PlatformDependent0.java:505)
    at io.netty.util.internal.PlatformDependent.objectFieldOffset(PlatformDependent.java:651)
    at io.netty.channel.nio.NioEventLoop$4.run(NioEventLoop.java:219)
    at java.security.AccessController.doPrivileged(AccessController.java:81)
    at io.netty.channel.nio.NioEventLoop.openSelector(NioEventLoop.java:209)
    at io.netty.channel.nio.NioEventLoop.<init>(NioEventLoop.java:142)
    at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:146)
    at io.netty.channel.nio.NioEventLoopGroup.newChild(NioEventLoopGroup.java:37)
    at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:84)
    at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:58)
    at io.netty.util.concurrent.MultithreadEventExecutorGroup.<init>(MultithreadEventExecutorGroup.java:47)
    at io.netty.channel.MultithreadEventLoopGroup.<init>(MultithreadEventLoopGroup.java:59)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:86)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:81)
    at io.netty.channel.nio.NioEventLoopGroup.<init>(NioEventLoopGroup.java:68)
    at io.vertx.core.net.impl.transport.Transport.eventLoopGroup(Transport.java:153)
    at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:143)
    at io.vertx.core.impl.VertxImpl.vertx(VertxImpl.java:92)
    at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:40)
    at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:32)
    at io.vertx.core.Vertx.vertx(Vertx.java:85)
    at io.quarkus.vertx.core.runtime.VertxCoreRecorder.initializeWeb(VertxCoreRecorder.java:106)
    at io.quarkus.vertx.core.runtime.VertxCoreRecorder.initializeWeb(VertxCoreRecorder.java:88)
    at io.quarkus.deployment.steps.VertxCoreProcessor$buildWeb41.deploy_0(VertxCoreProcessor$buildWeb41.zig:88)
    at io.quarkus.deployment.steps.VertxCoreProcessor$buildWeb41.deploy(VertxCoreProcessor$buildWeb41.zig:36)
    at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:186)
    at io.quarkus.runtime.Application.start(Application.java:89)
    at io.quarkus.runtime.Application.run(Application.java:226)
    at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:41)

To Reproduce
Steps to reproduce the behavior:

1. Checkout current master ( 64f0e690c when I hit this )
2. Build integration test module quarkus-integration-test-jpa-h2 with -Dnative
3. run existing test io.quarkus.it.jpa.h2.JPAFunctionalityInGraalITCase

Running GraalVM CE 19.3.1, 64 bit

The issue only manifests on the JDK11 version: no problem on GraalVM / JDK8.

[gwenneg]

That's a weird output indeed.

This is most likely related to #6956. I'll investigate this issue tonight unless it's been fixed by then.

[Sanne]

thanks @gwenneg , I wasn't planning to dive too deeply on this as I'm busy with other issues: so some help would be welcome.

Just wondering, nobody else hit this issue? Since it's in the integration tests, I wonder why nobody noticed yet - especially as #6956 seems was merged some days ago.

[gwenneg]

@gsmet This is probably a regression affecting 1.3.0.Alpha1. We will probably need to revert https://github.com/quarkusio/quarkus/pull/6956/commits/14a6eb6da5dbed554a3e537319e3ea9bcb39.

[gwenneg]

@Sanne I'm also surprised this didn't show up in CI. I'll try to figure this out tonight.

[gwenneg]

The GraalVM team commited https://github.com/netty/netty/commit/4980a6b30416af6fa73af1226ac305965cc516e7 in netty and it is part of netty 4.1.43.Final (and higher) so https://github.com/quarkusio/quarkus/commit/14a6eb6da5dbed554a3e537319e3ea9bcb39 should have been a safe commit.

[Sanne]

FYI we shouldn't drop code like 14a6eb6 as we hope to be able to have a switch in GraalVM which disables loading such metadata: it's better to have the Quarkus extension to have the definite say on what the compiler should do. The problem is otherwise different such metadata could have conflicting flags.

[gwenneg]

I didn't know that, we should revert https://github.com/quarkusio/quarkus/commit/14a6eb6da5dbed554a3e537319e3ea9bcb39 without a doubt then (and remove the TODO). Thanks for the info!

[Sanne]

thanks @gwenneg , I can confirm: I reverted 14a6eb6 and the problem is gone. I'll let you do the PR, please ping me when it's there I can expedite approve :)

More puzzling would be to figure out why that Netty resource is being ignored. It might relate to how resources are loaded: I just noticed I only have the issue on JDK11.

[Sanne]

@cescoffier FYI ^

[gsmet]

Are you sure you don't have an old Netty around? Just to be extra sure?

Because CI should have failed, it runs with Netty for each test basically.

[Sanne]

Are you sure you don't have an old Netty around? Just to be extra sure?

That was my first thought as well :) I checked the Maven dependency tree, it seems we're not pulling in some different/unexpected version.

Because CI should have failed, it runs with Netty for each test basically.

Is master being tested with JDK11 ? That seems to be the crucial difference - I'm confirming, will update the bug description.

[gsmet]

Typically, be sure you have fully built and installed master before testing things.

[gsmet]

Yes, it is. That's why I'm very surprised.

[gwenneg]

I just noticed I only have the issue on JDK11.

That's because the original GraalVM issue only happens with JDK > 9 according to the https://github.com/netty/netty/commit/4980a6b30416af6fa73af1226ac305965cc516e7 commit message.

[Sanne]

Confirmed, it was working just fine on GraalVM 19.3.1 / JDK 8 . Only fails on 11.

[Sanne]

@gsmet since maven's trees can't always be trusted, I also nuked all other versions I had in my local cache: re-run the build, and it didn't have to download anything so I guess it's really using that version.

I also see the json file within the jar.

[gsmet]

OK, I will check if I can reproduce it myself. If CI was red, I wouldn't but there's something fishy here. It might be our CI not testing the right thing. We need to get to the bottom of it.

https://github.com/quarkusio/quarkus/runs/428850800?check_suite_focus=true is green.

[gsmet]

So I confirm I have the same issue when building with JDK 11 and using GraalVM JDK 11.

[gsmet]

Lol:

[INFO] --- maven-failsafe-plugin:2.22.1:integration-test (default) @ quarkus-integration-test-jpa-h2 ---
[INFO] Tests are skipped.
[INFO] 
[INFO] --- maven-failsafe-plugin:2.22.1:verify (default) @ quarkus-integration-test-jpa-h2 ---
[INFO] Tests are skipped.

[gsmet]

https://github.com/quarkusio/quarkus/pull/7041

Good catch, @Sanne .

[Sanne]

Many thanks for the thourough checks @gsmet , I was very puzzled about "why only me?" :)