Exception when running a Quarkus native image with JFR enabled #270
Assignees
Labels
affects/21.2
bug
Something isn't working
pending upstream
Issue or PR pending action on upstream repository (oracle/graal)
Milestone
Comments
|
@vic-ma Please also add the "Actual Behaviour". I.e. the exception you see. Thanks! |
|
NVM. it's in the gist. Fails with: |
|
Here are some logs from an initial debugging attempt I did: Original program, Broken (1) A little hard to read because I didn't think of sharing this at first, but essentially I just added some print statements in the last two methods of the stack trace. Here is the diff. I did this in LabsJDK/Graal because I had trouble before using Mandrel with the OpenJDK I built from source. With the original program, the first log shows that the problematic event is The exception is |
|
The code in Graal that should be retransforming the event class to add the eventHandler field can be found here: I think at this point you can re-create this issue in the oracle/graal upstream repo with the details. |
jerboaa
added
the
pending upstream
|
As the issue is now tracked upstream we want the fix to land there first. |
|
Upstream fix. We should backport it to the 21.2 branch. oracle@bdaf8c2 @zakkak Thoughts? |
Sure. I would also suggest asking upstream to backport this for a potential pico release (e.g. 21.2.0.1). |
Do they update non-LTS releases that way? It would be news to me. I thought 21.3 only. |
|
They do provide bug fixes in some cases |
|
Closing this issue as it's on the 21.2 branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I am trying to build and run a native image of a simple Quarkus program, which has some JFR code in it [0]. The program is essentially just the Quarkus getting-started program with a few bits of JFR code added.
The native image builds without any issues, and when I run it without enabling JFR, the program runs as expected. However, when I enable JFR (regardless of starting a recording or not), it will cause an exception [1].
This exception is a little unpredictable though, because I've had a case where I rebuilt the native image, without making any changes to the source code, and the resulting native image did not give an exception when running it with JFR enabled. And when I started a recording on this native image, the resulting recording had the expected events in it [2].
Another interesting thing is that the likelihood of a build working seems to be proportional to the amount of JFR code. When I removed all of the code I added, the build seems to always work; when I changed it to have only one event instead of three, it seems to work about 50% of the time; and with the original code, a working native image is very rare.
Additionally, I've found that the issue is present when using upstream Graal as the native image builder, as well.
How To Reproduce
The commands for the first three steps are from a Mandrel blog post [3], with some modifications.
I've edited these commands to use the appropriate branches.
I've added the
--mandrel-repoflag to this command. I think the blog post might have left it out by accident.Configuration:
Expected behavior
The program should start, and not give an exception [2].
Additional context
[0] https://github.com/vic-ma/getting-started/blob/master/src/main/java/org/acme/getting/started/GreetingResource.java
[1] https://gist.github.com/vic-ma/c3773fbabf91c2126ae4795d2837ec77
[2] https://gist.github.com/vic-ma/cf34e1af9e8db28be6fb2867f0f613bd
[3] https://developers.redhat.com/blog/2021/04/14/mandrel-a-specialized-distribution-of-graalvm-for-quarkus#building_mandrel
The text was updated successfully, but these errors were encountered: