RFR: JDK-8248239: jpackage adds some arguments twice in case it is re-executed by JLI

Alexey Semenyuk alexey.semenyuk at oracle.com
Tue Jul 21 18:27:18 UTC 2020 

Hi Aleksei,

Looks good!

- Alexey

On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
> Hi,
>
> This is the updated fix which checks if LD_LIBRARY_PATH has been changed
> during jpackage executions:
>
> http://cr.openjdk.java.net/~avoitylov/webrev.8248239.03/
>
> The fix stores hash from LD_LIBRARY_PATH in _JPACKAGE_LAUNCHER env
> variable. Until C++14 becomes mandatory for OpenJDK, a custom hash
> algorithm is used because standard C++ hash requires -std=c++11 or
> -std=gnu++11 compiler options.
>
> All test/jdk/tools/jpackage tests but ModulePathTest3.java pass on Linux
> x86_64, MacOSX x86_64, and Windows x86_64. The test ModulePathTest3.java
> is excluded in test/jdk/ProblemList.txt (8248418 generic-all).
>
> Thanks,
>
> -Aleksei
>
> On 26/06/2020 20:23, Alexey Semenyuk wrote:
>> Hi Aleksei,
>>
>> I think the idea of partial reading data from cfg file when the
>> launcher is restarted has a flaw.
>> It would be better if app launcher can detect if it was restarted and
>> if it was, not read cfg file at all, but pass command line arguments
>> as is in JLI_Launch().
>> Let my think on ideas how to address this.
>>
>> - Alexey
>>
>> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>>> Hi Alexey,
>>>
>>> Thank you for looking into it. As far as using parent pid, it does not
>>> seem to work as example [1] demonstrates. The parent process remains the
>>> same after re-execution and does not become the current process.
>>>
>>> I checked passing arguments in the "ArgOption" section using several
>>> cases [2, 3, 4] with the proposed fix and app re-execution. The proposed
>>> fix handles this case well, and the results are the same as without the
>>> fix when the app is not re-executed.
>>>
>>> Case [3] where only JavaOptions without ArgOptions are passed to app
>>> looks suspicious because default ArgOptions are not used. But it works
>>> the same way without the proposed fix, which seems like a different
>>> issue. According to jpackage documentation:
>>>
>>>     --arguments main class arguments
>>>           Command line arguments to pass to the main class if no command
>>> line arguments are given to the launcher.
>>>
>>> I filed a separate issue [5] to handle that.
>>>
>>> Thanks,
>>> -Aleksei
>>>
>>>
>>> [1]
>>> cd jdk-dev
>>> make jdk-image
>>> export PATH=build/linux-x86_64-server-release/images/jdk/bin:$PATH
>>> export
>>> LD_LIBRARY_PATH=build/linux-x86_64-server-release/images/jdk/lib/server
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --verbose --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>> -------------
>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>> pid: 15927, parent  process: /bin/bash
>>> JvmLauncher args: 10 [/home/sample/jdk-dev/output/app/bin/app
>>> -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>> pid: 16007, current process: /home/sample/jdk-dev/output/app/bin/app
>>> pid: 15927, parent  process: /bin/bash
>>> JvmLauncher args: 15 [/home/sample/jdk-dev/output/app/bin/app
>>> -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam1=Param1 --module-path
>>> /home/sample/jdk-dev/output/app/lib/app/mods -m
>>> com.hello/com.hello.Hello -Dparam2=Param2 B B2 B ]
>>> -------------
>>>
>>> [2]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app
>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>> JvmLauncher args: 9 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello A A2 A ]
>>>
>>> [3]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2
>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>> JvmLauncher args: 7 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 ]
>>>
>>> [4]
>>> jpackage --dest output --name app --type app-image --module-path
>>> input-modules --module com.hello/com.hello.Hello --arguments "A A2 A"
>>> --java-options -Dparam1=Param1
>>> ./output/app/bin/app -Dparam2=Param2 B B2 B
>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>> B2 B ]
>>> JvmLauncher args: 10 [output/app/bin/app -Dparam1=Param1 --module-path
>>> output/app/lib/app/mods -m com.hello/com.hello.Hello -Dparam2=Param2 B
>>> B2 B ]
>>>
>>> [5] https://bugs.openjdk.java.net/browse/JDK-8248397
>>>
>>>
>>> On 24/06/2020 19:34, Alexey Semenyuk wrote:
>>>> Aleksei,
>>>>
>>>> If I get it right, the fix would not work for the case when there are
>>>> `arguments` properties in `ArgOptions` section of a config file.
>>>> Why not just check if the parent process is the same executable as the
>>>> current one and if this is the case don't read data from the config
>>>> file but pass executable arguments as is in JLI_Launch() call?
>>>>
>>>> - Alexey
>>>>
>>>> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>>>>> Hi,
>>>>>
>>>>> There are systems that update LD_LIBRARY_PATH or directly return
>>>>> JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c
>>>>> file to request re-execution of the current executable. This leads to
>>>>> the fact that jpackage application adds some provided arguments twice.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
>>>>> Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
>>>>>
>>>>> The root cause of the issue is that jpackage application expects one
>>>>> number of arguments but JLI reexecutes them with another number of
>>>>> arguments.
>>>>>     For example, a jpackage application can be run with arguments:
>>>>>        ./app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>> it adds arguments from the config file and calls JLI with arguments:
>>>>>        app/bin/app -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello
>>>>> -Dparam2=Param2 B1 B2 B3
>>>>> JLI re-executes the app with new arguments so the app adds some
>>>>> arguments one more time after the re-execution.
>>>>>        ./app/bin/app -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
>>>>>
>>>>> A step by step example that illustrates the issue:
>>>>>
>>>>> Run jpackage to create an executable application:
>>>>>      jpackage --dest output --name app --type app-image --module-path
>>>>> input-modules --module com.hello/com.hello.Hello --arguments "A1 A2
>>>>> A3"
>>>>> --verbose --java-options -Dparam1=Param1
>>>>>
>>>>> Executable application with the app/lib/app/app.cfg config file is
>>>>> created:
>>>>> ---- app.cfg  ----
>>>>> [Application]
>>>>> app.name=app
>>>>> app.version=1.0
>>>>> app.runtime=$ROOTDIR/lib/runtime
>>>>> app.identifier=com.hello
>>>>> app.classpath=
>>>>> app.mainmodule=com.hello/com.hello.Hello
>>>>>
>>>>> [JavaOptions]
>>>>> java-options=-Dparam1=Param1
>>>>>
>>>>> [ArgOptions]
>>>>> arguments=A1
>>>>> arguments=A2
>>>>> arguments=A3
>>>>> -----------
>>>>>
>>>>> Run the application:
>>>>>       ./output/app/bin/app -Dparam2=Param2 B1 B2 B3
>>>>>
>>>>> Chain of JDK methods execution:
>>>>>
>>>>> LinuxLauncher main()
>>>>>       args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher createJvmLauncher()
>>>>>       args: 4 [-Dparam2=Param2 B1 B2 B3 ]
>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>> app.cfg
>>>>>       args: 10 [app/bin/app -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher Jvm::launch() -  JLI re-executes the app
>>>>> LinuxLauncher main()
>>>>>      args: 10 [app/bin/app -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>> AppLauncher createJvmLauncher()
>>>>>       args: 9 [-classpath  -Dparam1=Param1 -m com.hello/com.hello.Hello
>>>>> -Dparam2=Param2 B1 B2 B3 ]
>>>>> JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from
>>>>> app.cfg
>>>>>       args: 15 [./app/bin/app -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
>>>>>        ^^^
>>>>>
>>>>> Some arguments like "-classpath  -Dparam1=Param1 -m
>>>>> com.hello/com.hello.Hello" are added twice.
>>>>>
>>>>> Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
>>>>> regressions on Linux, Windows, Mac. On systems affected, the tests
>>>>> now pass.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> -Aleksei
>>>>>
>>>>>

More information about the core-libs-dev mailing list