JDK-8293806 : JDK_JAVA_OPTIONS picked up twice if launcher re-executes itself
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 20
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • OS: linux
  • CPU: generic
  • Submitted: 2022-09-14
  • Updated: 2022-12-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8170832 - Add a new launcher environment variable JAVA_OPTIONS
Relates :  
JDK-8298638 - Cleanup of unix java_md.c for better re-exec handling
Description
Under some circumstances, the launcher have to update LD_LIBRARY_PATH, but the runtime linker only considers this variable during application startup, so after updating LD_LIBRARY_PATH the launcher must re-execute it self by calling execvp(). 

The decision to re-launch is made after all options from all sources (JDK_JAVA_OPTIONS, @argfile) already been processed and copied to argv[] array. Thus, parameters passed through JDK_JAVA_OPTIONS variable are processed twice.

If an option cannot be accepted twice (e.g., -agentlib), the application fails to  start.

We cannot just remove the JDK_JAVA_OPTIONS variable because some applications (e.g. IDEs) use it to pass user parameters through the chain of child java processes.

It happens under following conditions:

1. Under MUSL libc launcher have to set LD_LIBRARY_PATH to resolve dependency between libjava and libjvm
2. On AIX launcher have to set LD_LIBRARY_PATH because the runtime linker doesn't support $ORIGIN
3. User set LD_LIBRARY_PATH variable to some location containing libjvm.so. According to comment in java_md.c, LD_LIBRARY_PATH have to be updated to avoid recursion.
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11538 Date: 2022-12-06 14:04:44 +0000
06-12-2022
Before (set by user): LD_LIBRARY_PATH=/usr/bin:/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk/lib/server After (set for launcher re-execution): LD_LIBRARY_PATH=/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk/lib/server:/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk/lib:/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk/../lib:/usr/bin:/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk/lib/server
30-09-2022
The output of the script reproducing the problem with unmodified jdk11 on Alpine/Musl localhost:~$ ./runme NOTE: Picked up JDK_JAVA_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 ----_JAVA_LAUNCHER_DEBUG---- Launcher state: First application arg index: -1 debug:on javargs:off program name:java launcher name:openjdk javaw:off fullversion:11.0.1+13-LTS Java args: Command line args: argv[0] = /ws/jdk-11.0.1/bin/java argv[1] = -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 argv[2] = -version JRE path is /ws/jdk-11.0.1 jvm.cfg[0] = ->-server<- jvm.cfg[1] = ->-client<- 1 micro seconds to parse jvm.cfg Default VM: server Does `/ws/jdk-11.0.1/lib/server/libjvm.so' exist ... yes. mustsetenv: TRUE TRACER_MARKER:About to EXEC NOTE: Picked up JDK_JAVA_OPTIONS: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 ----_JAVA_LAUNCHER_DEBUG---- Launcher state: First application arg index: -1 debug:on javargs:off program name:java launcher name:openjdk javaw:off fullversion:11.0.1+13-LTS Java args: Command line args: argv[0] = /ws/jdk-11.0.1/bin/java argv[1] = -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 argv[2] = -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 argv[3] = -version JRE path is /ws/jdk-11.0.1 jvm.cfg[0] = ->-server<- jvm.cfg[1] = ->-client<- 1 micro seconds to parse jvm.cfg Default VM: server Does `/ws/jdk-11.0.1/lib/server/libjvm.so' exist ... yes. mustsetenv: TRUE JVM path is /ws/jdk-11.0.1/lib/server/libjvm.so 1 micro seconds to LoadJavaVM JavaVM args: version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 5 option[ 0] = '-Dsun.java.launcher.diag=true' option[ 1] = '-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005' option[ 2] = '-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005' option[ 3] = '-Dsun.java.launcher=SUN_STANDARD' option[ 4] = '-Dsun.java.launcher.pid=26796' ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options. Error occurred during initialization of VM agent library failed to init: jdwp
30-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10430 Date: 2022-09-26 18:15:17 +0000
26-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10420 Date: 2022-09-26 09:46:36 +0000
26-09-2022
I'm in process of preparing the patch.
22-09-2022
Use the following script to reproduce the issue: #!/bin/sh TESTJAVA=/export/ojdk/jdk_virgin/build/linux-x86_64-server-fastdebug/images/jdk JDK_JAVA_OPTIONS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 export JDK_JAVA_OPTIONS LD_LIBRARY_PATH=/usr/bin:${TESTJAVA}/lib/server export LD_LIBRARY_PATH ${TESTJAVA}/bin/java -version
15-09-2022