RFR: JDK-8248239: jpackage adds some arguments twice in case it is re-executed by JLI
alexander.matveev at oracle.com
alexander.matveev at oracle.com
Fri Jul 24 22:37:03 UTC 2020
Looks good.
Thanks,
Alexander
On 7/24/20 12:39 PM, Andy Herrick wrote:
> looks good
>
> /Andy
>
> On 7/21/2020 2:27 PM, Alexey Semenyuk wrote:
>> 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