EXCEPTION_ACCESS_VIOLATION (0xc0000005) with jbyte_disjoint_arraycopy #887
Comments
|
@gschrader This is looking like an Oracle JDBC driver issue (it's a byte buffer copy operation from Java to native). Recommend bringing this to ORacle support in the first instance |
|
Thanks @karianna, we're narrowing in on the cause, we think it's something in our code that was recently committed that JDK 11 had no problem with but 17 does. We're currently doing a bisect to narrow it down further. We've ruled out later JDK 11 releases. Confirmed it happens as well with the latest Zulu JDK 17. Nothing jumped out from the heap dump so I don't think it's memory related. Can I ask why you think it is related to the Oracle JDBC driver? If it's the blurb in the I'll follow up when we learn more and then I can get clarification where I need to go to bring it to "Oracle support". |
|
We've faced a similar case; somebody wanted to run an executable Jar from a batch file when Open JDK -17 was included in the delivered package together with the executable JAR and the launching batch file. The irregularity is that the case happened when the package had been downloaded from FTP as a directory. Remarkable that it happens ONLY in the downloaded package, even on the same machine, where it has been uploaded from. At the same time, this does not occur, when the package has been zipped before uploaded and unzipped after download- in this case, it works great. It sounded strange, but it is a fact. |
|
@SimonCanJer I'm not sure I totally understand your case, it sounds like your JDK was corrupted when downloaded, from a repackaged application. I did just confirm the SHA256 of my download and it appears to match. |
|
It happened not only on my machine but on the machines of yet number of
guys. But, if the package (java-17 folder + batch+ jar) had been zipped
before uploading, then finally it works as expected after the downloaded
zip expanded and no error has occurred. I have checked the
problematic dll, and it is the same, as in my Java folder, where I have
copied it initially from. I thought that may be the problem with
permissions: a nonzipped package is downloaded by FileZilla, while a zipped
package is decompressed by a call from UI (from my name)
…On Tue, Sep 19, 2023 at 5:27 PM Glen Schrader ***@***.***> wrote:
@SimonCanJer <https://github.com/SimonCanJer> I'm not sure I totally
understand your case, it sounds like your JDK was corrupted when
downloaded, from a repackaged application. I did just confirm the SHA256 of
my download and it appears to match.
—
Reply to this email directly, view it on GitHub
<#887 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACMWJV5OAKFK3ZQUGFSSBTLX3GTULANCNFSM6AAAAAA4GLPHJQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I think the |
|
I'm not sure what happened to my last response from a couple of weeks ago, I must have not pressed the submit button We have narrowed this down to a test that goes against a Spring controller that does file upload/downloads, the test itself doesn't crash but the next one that runs does. I thought perhaps it was due to a mix of webflux/webmvc that we have going on but now I think it might be as simple as missing a DirtiesContext . As for the Oracle driver, I had pasted a bunch of other examples of the crash that didn't have Oracle driver in the log so I think might be a red herring. Anyway I'll know more in a while once this next test run either completes or crashes. |
|
The DirtiesContext didn't make a difference however changing the code to be pure WebMVC seems to have prevented the crash. Ideally the JVM wouldn't crash or at least provide some more breadcrumbs to figure it out. Maybe it's a Spring issue but I doubt the mixture of code would be supported so I'm not going to try to explain it to the Spring team. So I think closing this issues make sense. |
|
For reference: quarkus --version && gradle --version# 3.10.2
# ------------------------------------------------------------
# Gradle 8.7
# ------------------------------------------------------------
# Build time: 2024-03-22 15:52:46 UTC
# Revision: 650af14d7653aa949fce5e886e685efc9cf97c10
# Kotlin: 1.9.22
# Groovy: 3.0.17
# Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023
# JVM: 21.0.3 (Eclipse Adoptium 21.0.3+9-LTS)
# OS: Windows 10 10.0 amd64If I try to run a sample Quarkus project with Gradle [1], I get the exact same error under Git Bash, but not under PowerShell. [1] If I run |
Please provide a brief summary of the bug
We have our unit tests running in an ADO agent, split across several jobs. One particular job is always causing the JVM to crash once it hits a certain test.
The log file does not contain any java frames so it's hard to tell what code could be causing the crash. It's not always the jbyte, we've also seen jint, jshort and jlong. It's always the junit "Test worker" thread that crashes. If we ignore the test, it appears to fail on the next test.
We upgraded to the latest Temurin release, we we're initially using 17.0.6+10.
We've upgraded several libraries (i.e. spring boot to 2.7.15) and JDBC driver to no avail.
I'm speculating it could be memory related so I'm currently running the job to grab a JVM heap dump.
hs_err_pid.log file will be attached
hs_err_pid6484.log
Please provide steps to reproduce where possible
Unfortunately I don't think we can reproduce it in isolation, the test works just fine on its own.
Expected Results
The JVM to not crash or at least give us more clues as to why it is crashing.
Actual Results
The JVM crashes with EXCEPTION_ACCESS_VIOLATION (0xc0000005)
What Java Version are you using?
openjdk version "17.0.8" 2023-07-18 OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7) OpenJDK 64-Bit Server VM Temurin-17.0.8+7 (build 17.0.8+7, mixed mode, sharing)
What is your operating system and platform?
Windows Server 2016 , 64 bit Build 14393 (10.0.14393.5786)
How did you install Java?
zip from https://adoptium.net
Did it work before?
It was working in my java17 branch before I rebased on master, nothing obvious jumps out as to what change could have caused it.Did you test with the latest update version?
Did you test with other Java versions?
We haven't yetRelevant log output
The text was updated successfully, but these errors were encountered: