fatal error: DEBUG MESSAGE: duplicated predicate failed which is impossible

claudia-schmid commented 1 year ago

Please provide a brief summary of the bug

When starting our application we load about 700mb of data into memory and then do various calculations on this data (including running several Groovy scripts). Since upgrading to 17.0.7+7 we are seeing frequent JVM crashes. This happens both in Eclipse (both Debug and Run) as well as in an installation environment. The crash is always due to fatal error: DEBUG MESSAGE: duplicated predicate failed which is impossible

Since adding the JVM flag -Xbatch the error has not occurred again.

Note that the attached hs_err file is for a smaller data set than mentioned above. hs_err_pid159836.log

Please provide steps to reproduce where possible

I have more hs_err files that I could provide. I am also open to trying out things that could help to localize the problem. However, I am unable to create a minimal, reproducible example.

Expected Results

Normal processing

Actual Results

JVM crash

What Java Version are you using?

OpenJDK 64-Bit Server VM Temurin-17.0.7+7 (build 17.0.7+7, mixed mode, sharing)

What is your operating system and platform?

Windows 10 , 64 bit Build 19041 (10.0.19041.2913)

How did you install Java?

binary archive

Did it work before?

On OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode) and earlier versions there was no crash

Did you test with the latest update version?

17.0.7+7 is the latest version

Did you test with other Java versions?

No response

Relevant log output

No response

karianna commented 1 year ago

Also, what version of Groovy are you using?

karianna commented 1 year ago

Further debugging advice from GPT-4 which I've edited for your use. case:

The error message you're seeing is a JVM crash related to the macro assembler in the HotSpot Just-In-Time (JIT) compiler on x86 platforms. The specific error is raised when a duplicated predicate fails, which should be an impossible condition according to the code comment.

This kind of error is usually caused by one or more of the following factors:

A bug in the JVM itself: The HotSpot JIT compiler may have a bug or an unexpected condition that caused it to crash. You may want to check for updates to the JVM or report the issue to the developers if it persists.
Native code: If your application is using native libraries (JNI or JNA), they could be causing the crash. Make sure the native libraries are compatible with your JVM version and that they don't have any known issues.
Hardware issues: Sometimes, hardware problems like faulty memory can cause crashes. You might want to check your hardware to ensure it's functioning properly.
Unsupported JVM flags or configuration: If you're using any non-standard JVM flags or custom configurations, they could be causing instability. Revert to the default configuration and see if the issue persists.

To troubleshoot the issue, you can take the following steps:

Run your application with a different JVM (like OpenJDK or another vendor's JVM) to see if the issue is specific to a particular JVM implementation.
Check your native libraries and ensure they're up-to-date and compatible with your JVM.
Try running your application with the default JVM configuration (no custom flags) to see if the issue persists.

claudia-schmid commented 1 year ago

Tests (without the -Xbatch flag). The tests were done individually i.e. reverting to the original setup after each test.

Use Oracle JDK Java HotSpot(TM) 64-Bit Server VM (build 17.0.7+8-LTS-224, mixed mode, sharing) -> JVM crashes
Reduce the JDK flags to -Dqnamic.properties=../../../planopt_railopt/install/serverx.prop -Dstartup.xml.file=startup.xml -Djava.library.path=../../../planopt_railopt/lib --add-modules jdk.management.agent --add-exports jdk.management.agent/jdk.internal.agent=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.math=ALL-UNNAMED -> JVM crashes
Update groovy from 3.0.9 (the version we are currently using) to 3.0.17 -> JVM crashes

We are not using any native libraries.

In your opinion, is it logical that the JVM flag -Xbatch would prevent the crash from happening or is this just a fluke?

karianna commented 1 year ago

-Xbatch means the JIT spends more time compiling and will backtrack less often. Chances are it's a backtrack (deopt) in the regular mode that's causing this crash. I'll submit the log to JBS.

claudia-schmid commented 1 year ago

Thank you very much!

claudia-schmid commented 1 year ago

As a follow-up, unfortunately, the -Xbatch flag does not solve the problem. The JVM takes longer to crash but still crashes after several hours.

github-actions[bot] commented 11 months ago

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable. It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

karianna commented 11 months ago

@claudia-schmid Just reveisting this one. Have you tried the latest 17.0.8 release?

claudia-schmid commented 11 months ago

@karianna We are currently testing 17.0.8. So far so good. No more crashes have occurred. If it ok with you I would like to keep this issue open for a few more weeks until we have completed our tests. Many thanks!

claudia-schmid commented 10 months ago

@karianna with 17.0.8 we have not observed any more crashes. I am going to close this issue.

adoptium / adoptium-support