Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

UnsupportedFeatureError: The offset of private final java.util.Set #7035

Closed
Sanne opened this issue Feb 6, 2020 · 21 comments · Fixed by #7041
Closed

UnsupportedFeatureError: The offset of private final java.util.Set #7035

Sanne opened this issue Feb 6, 2020 · 21 comments · Fixed by #7041
Assignees
@gwenneg
Labels
area/vertx kind/bug Something isn't working triage/regression
Milestone
1.3.0.Alpha2

Comments

@Sanne
Copy link
Member

Sanne commented Feb 6, 2020 •
edited

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 ( 64f0e69 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.
@Sanne Sanne added kind/bug Something isn't working area/vertx labels Feb 6, 2020
@gwenneg
Copy link
Member

gwenneg commented Feb 6, 2020

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
Copy link
Member Author

Sanne commented Feb 6, 2020 •
edited

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
Copy link
Member

gwenneg commented Feb 6, 2020

@gsmet This is probably a regression affecting 1.3.0.Alpha1. We will probably need to revert 14a6eb6.

@gwenneg
Copy link
Member

gwenneg commented Feb 6, 2020

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

@gwenneg gwenneg added this to the 1.3.0 milestone Feb 6, 2020
@gwenneg
Copy link
Member

gwenneg commented Feb 6, 2020

The GraalVM team commited netty/netty@4980a6b in netty and it is part of netty 4.1.43.Final (and higher) so 14a6eb6 should have been a safe commit.

@Sanne
Copy link
Member Author

Sanne commented Feb 6, 2020

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
Copy link
Member

gwenneg commented Feb 6, 2020 •
edited

I didn't know that, we should revert 14a6eb6 without a doubt then (and remove the TODO). Thanks for the info!

@gwenneg gwenneg self-assigned this Feb 6, 2020
@Sanne
Copy link
Member Author

Sanne commented Feb 6, 2020

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
Copy link
Member Author

Sanne commented Feb 6, 2020

@cescoffier FYI ^

@gsmet
Copy link
Member

gsmet commented Feb 6, 2020

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
Copy link
Member Author

Sanne commented Feb 6, 2020

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
Copy link
Member

gsmet commented Feb 6, 2020

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

@gsmet
Copy link
Member

gsmet commented Feb 6, 2020

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

@gwenneg
Copy link
Member

gwenneg commented Feb 6, 2020

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 netty/netty@4980a6b commit message.

@Sanne
Copy link
Member Author

Sanne commented Feb 6, 2020

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

@Sanne
Copy link
Member Author

Sanne commented Feb 6, 2020

@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
Copy link
Member

gsmet commented Feb 6, 2020

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
Copy link
Member

gsmet commented Feb 6, 2020

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

@gsmet
Copy link
Member

gsmet commented Feb 6, 2020

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 gsmet mentioned this issue Feb 6, 2020
Merged
@gsmet
Copy link
Member

gsmet commented Feb 6, 2020

#7041

Good catch, @Sanne .

@Sanne
Copy link
Member Author

Sanne commented Feb 6, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gwenneg gwenneg

Labels
area/vertx kind/bug Something isn't working triage/regression
Projects
None yet
Milestone
1.3.0.Alpha2
Development

Successfully merging a pull request may close this issue.

Revert removal of a Netty GraalVM tweak gsmet/quarkus
3 participants
@Sanne @gsmet @gwenneg