On Mon, 26 Sep 2022 18:15:17 GMT, Dmitry Samersoff <dsamers...@openjdk.org> wrote:
> If the user has set LD_LIBRARY_PATH to use a particular libjvm.so, options > from the JDK_JAVA_OPTIONS environment variable are picked up twice. > > If an option cannot be accepted twice (e.g., -agentlib), the application > fails to start. > > The same happens on operating systems that doesn't support $RPATH/$ORIGIN and > always have to set LD_LIBRARY_PATH and re-exec the launcher. > > The fix adds one additional argument - orig_argv to JLI_Launch() and use it > in on relaunch in execv() call. > > All relevant jtreg tests are passed. _I updated description in the CR, https://bugs.openjdk.org/browse/JDK-8293806 but for convenience copy it here. Also, I added some debug output to the comments for CR_ 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. ------------- PR: https://git.openjdk.org/jdk/pull/10430
