EXCEPTION_ACCESS_VIOLATION when starting application with parameters

[ssindelar]

We are currently moving from oracle jdk 8 to openjdk 12, but we hit a road block.

When we start our application with parameters most of the time >90% we directly get an EXCEPTION_ACCESS_VIOLATION crash in the jvm.dll. Even before the first line of our code is executed. Starting without parameter works, but also not 100% (jvm just terminates without any error).

This happens with the current JDK 11 and 12 builds. JDK 8 works fine.

hs_err_pid14528.log

Update:
Some additional notes:

• somehow the application is now ultra slow if I start it, but no error happens (gone after a restart)
• Two colleagues also tried it. For one it works (Win10) for other not (Win7, same error). I also use Win10. Hardware of the one where it works is newer.
• Using more parameters also reduces the chance of the crash.
• Simple projects (one class, no dependencies) work

[karianna]

Are you able to try the adoptopenjdk.net/upstream.html builds instead and report back here?

[ssindelar]

From what I can see it doesn't make a difference.

hs_err_pid17268.log

Further information that may help:

• Application is launched from Eclipse with the following call:
  C:\Program Files\Java\openjdk-11u-11.0.5_2\bin\javaw.exe -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:20389 "-javaagent:C:\dev\tools\eclipse\configuration\org.eclipse.osgi\1218\0\.cp\lib\javaagent-shaded.jar" -Dfile.encoding=Cp1252 "@C:\workspaces\repo2\Repo\Netbox\batch-manager\.temp-BatchManager - Workspace CommserviceJ-classpath-arg-1565875536169.txt" net.ibhks.batchmanager.BatchManager --commservicej.enabled=true --ignite.homePath=../../userdata/netbox/ignite2
  Classpath file: temp-BatchManager - Workspace CommserviceJ-classpath-arg-1565875536169.txt
• We need a lot of different dependencies (some are quite old).
• Starting the application with the call above without eclipse also causes the crash.

[karianna]

Interesting OK so looks like a genuine upstream bug.

[jwachter]

We are running into the same issue, currently on multiple machines with different versions of Windows 10 (1709+) and with AdoptOpenJDK 11.0.3, 11.0.4 and 11.0.5 as well as the current OpenJDK 11+28 and the Zulu JDK 11. We investigated it a bit further as it is a bigger blocker for development and have some additional insights and even a workaround that seems to solve it, for us at least.

It seems to be related to the combination of an @argumentFile that contains the classpath and giving program arguments afterwards. Without parameters it did not happen, same if there was no argument file. Also it seems to correlate with the size of the argument file contents or arguments in how reliably it happens.

For us the main point to dig further was that it only happens to Eclipse users in our organisation and not to IntelliJ IDEA users. Also with the Commandline used by Eclipse as mentioned above it happens also when invoked from outside Eclipse whereas with the IntelliJ Commandline it doesn't happen outside Eclipse.

The difference here seems to be that Eclipse JDT generates and argument file as a single line without a linebreaks,

Eclipse
-classpath <classpath>

IntelliJ
-classpath <newline> <classpath> <newline>
Adding a final newline to the Eclipse file makes it work for us both in the IDE and on the Commandline. So we created an internal Eclipse Feature Patch that Patches ClasspathShortener to add a newline at the end of the file.

So the issue seems to be that in combination with the number/size of program arguments and the size of the argumentfile, if the argumentFile has no newline at the end the JVM reads past the end into memory it is not allowed to read.

There seems to already be an upstream issue at JDK-8231863. So I mainly documented it here for people also hitting this issue.

[nlmarco]

This still exists! I just encountered it with Eclipse 20181214-0600 and the OpenJDK jdk-11.0.7+10 (Windows, 64 bit).

It makes no difference, whether I launch the program in debug-mode or not. I always get:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000007fedddbac36, pid=5556, tid=5520
#
# JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0x66ac36]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# X:\v18.bouyfr\xstream\wincash.resources\hs_err_pid5556.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
#

Here's the log mentioned in the above message:
hs_err_pid5556.log

If I do not configure any program arguments, it works. VM arguments seem to be irrelevant.

Can/should I reopen this issue? It seems impossible to reopen. Or should I create a new issue?

[jwachter]

See my comment in #1713 ;)