Access checking fails due to wrong getCallerClass() results

[dmlloyd]

I don't know the exact issue but I think Reflection.getCallerClass() is (maybe only sometimes) wrong now. If you look at the stack trace of quarkusio/quarkus#3074, you can see that the result of Reflection.getCallerClass() within Constructor was com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl, which is one frame lower than the class which should have been returned. I'm thinking it might be a result of a14d2f1, specifically the factoring out of StackTraceUtils. The problem occurs in 19.1.0 but not 19.0.x.

Reference: quarkusio/quarkus#3074

/cc @christianwimmer

[christianwimmer]

Fixed in 506f2f1

[gsmet]

@christianwimmer cool thanks. Any idea when the next micro release is due? We can't upgrade Quarkus to use 19.1.0 until this one is fixed.

Thanks!

[christianwimmer]

@gsmet There should be a 19.1.1 soon for the Oracle's July critical patch update. I'll work to get it in there.

In general, we would like to test Quarkus before we make a release (ideally in our gate before every merge). Can you provide @cstancu with some input on what and how to test automatically?

[dmlloyd]

It's quite easy. You do need to have Apache Maven on your PATH though.

• Check out the project
• Set JAVA_HOME either to the GraalVM distro or to a JVMCI-enabled JDK (only Java 8 is supported but 11 should come soon)
• Set GRAALVM_HOME to the GraalVM distro
• mvn clean install -Dnative

It takes quite a while to build all the integration tests with native unfortunately.

[christianwimmer]

Is there a possibility to run the same tests without needing the Quarkus repository, i.e., just with a Quarkus release on Maven?

[dmlloyd]

The integration tests are not runnable without checking out the source at present.

[cstancu]

@dmlloyd I tried the quarkus integration tests with the GraalVM latest master and Quarkus - Integration Tests - Vert.x fails with Error: Already registered: sun.nio.ch.DatagramChannelImpl.disconnect0(FileDescriptor, boolean) com.oracle.svm.core.util.UserError$UserException: Already registered: sun.nio.ch.DatagramChannelImpl.disconnect0(FileDescriptor, boolean). This is likely because you still have the substitution in your repo and in the meantime, we integrated the PR for the same substitution in our repo.

[cstancu]

@dmlloyd Would it be possible to make a Quarkus release variant that also includes the integration tests in the future? That would make it easier for us to integrate them in our internal CI.

[bobmcwhirter]

Yeah until there is a release and Q rebases we will have this sorta issue. We have our workarounds that we can only remove once stuff is upstream and released.

…

On Tue, Jul 9, 2019 at 6:50 PM Codrut Stancu ***@***.***> wrote: @dmlloyd <https://github.com/dmlloyd> I tried the quarkus integration tests with the GraalVM latest master and Quarkus - Integration Tests - Vert.x fails with Error: Already registered: sun.nio.ch.DatagramChannelImpl.disconnect0(FileDescriptor, boolean) com.oracle.svm.core.util.UserError$UserException: Already registered: sun.nio.ch.DatagramChannelImpl.disconnect0(FileDescriptor, boolean). This is likely because you still have the substitution in your repo and in the meantime, we integrated the PR for the same substitution in our repo. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1479?email_source=notifications&email_token=AAAD4T7FRGPTS7SN3PNRCIDP6UI3XA5CNFSM4H65IJUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZRYMDI#issuecomment-509838861>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAD4T7TQOMM4QGXVJYAEY3P6UI3XANCNFSM4H65IJUA> .

[christianwimmer]

How many workarounds are there in Quarkus? Can you push them all out before we make the next release?

In the meantime and to run with multiple different GraalVM release, you can make substitutions conditional on the GraalVM version number by using the onlyWith attribute of substitutions.

Currently we have a bit of a testing issue: until we reach a point where you can test the Quarkus master with the most recent GraalVM release, and we can test the most recent Quarkus release with GraalVM master, there will always be a manual integration step that discovers some problems.

For us it is also difficult (for various non-technical reasons) to test based on the Quarkus source code, so having a way to run the Quarkus test only using Maven artifacts would be very helpful.

[dmlloyd]

How many workarounds are there in Quarkus?

Usually not many. In fact I'm surprised about the Vert.x problem because nothing like that came up in my last round of tests, just a few days ago.

Using onlyWith is a good idea; I'll pass that on.

[dmlloyd]

What's the best API to query to get the current GraalVM version?

[christianwimmer]

The system property org.graalvm.version contains the GraalVM version string.

@olpaw @gilles-duboscq we should probably add a GraalVM API (either in ImageInfo or even better somewhere that is native image independent) to do version comparisons by string, i.e., to ask queries like "am I running on GraalVM version 19.1 or higher".

[dmlloyd]

quarkusio/quarkus#3188 should hopefully fix the problem.

[cstancu]

@dmlloyd I can confirm that the latest Quarkus master now successfully builds with the latest GraalVM master using mvn clean install -Dnative.