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

[Alexey Semenyuk]

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
>>>
>>>