PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached
Yasumasa Suenaga
yasuenag at gmail.com
Thu Nov 16 12:09:43 UTC 2017
Hi David, Serguei,
>> The test logic is adding it in AttachFailedTestBase.java:
>>
>> 45 return Paths.get(System.getProperty("test.nativepath"), "lib", libname)
>> 46 .toAbsolutePath()
>> 47 .toString();
Thanks!
I've fixed it in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.03/
I've tested it as below. It works fine:
$ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:$NATIVE_PATH hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed
$ echo $NATIVE_PATH
/<Path to configuration>/images/test/hotspot/jtreg/native
Thanks,
Yasumasa
On 2017/11/16 16:49, serguei.spitsyn at oracle.com wrote:
> On 11/15/17 23:29, David Holmes wrote:
>> On 16/11/2017 4:43 PM, serguei.spitsyn at oracle.com wrote:
>>> On 11/15/17 18:11, David Holmes wrote:
>>>> Hi Serguei,
>>>>
>>>> > /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so'
>>>>
>>>> There should not be any "/lib/" in that path
>>>
>>> Right, it should not be.
>>
>> The test logic is adding it in AttachFailedTestBase.java:
>>
>> 45 return Paths.get(System.getProperty("test.nativepath"), "lib", libname)
>> 46 .toAbsolutePath()
>> 47 .toString();
>>
>> but it shouldn't.
>
> Nice catch!
> I looked right to these lines and overlooked it. :)
>
> Thanks,
> Serguei
>
>>
>> David
>> -----
>>
>>
>>> This is the script I'm using to run the tests:
>>>
>>> #!/bin/sh
>>>
>>> REPO=/var/tmp/sspitsyn/jdk.attach
>>> IMAGES=${REPO}/build/linux-x86_64-normal-server-release/images
>>> export JAVA_HOME=${IMAGES}/jdk
>>> export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native
>>> export NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native
>>> echo "JAVA_HOME = $JAVA_HOME"
>>>
>>> /java/re/jtreg/4.2/nightly/binaries/jtreg/bin/jtreg -nativepath:${NATIVE_PATH} \
>>> $REPO/open/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed
>>>
>>>
>>> This is a part of log with the reported error from the AttachException.jtr:
>>>
>>> [TestNG] Running:
>>> serviceability/dcmd/jvmti/AttachFailed/AttachException.java
>>>
>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor'
>>> Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 8689, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so]'
>>> Command returned with exit code 0
>>> ---------------- stdout ----------------
>>> 8689:
>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so was not loaded.
>>> /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native*/lib*/libException.so: cannot open shared object file: No such file or directory
>>>
>>>
>>> These are the locations of the libException.so:
>>> build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/libException.so
>>> build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/lib/libException.so
>>>
>>>
>>> The tests fail with the "NATIVE_PATH=${IMAGES}/test/hotspot/jtreg/native"
>>> but pass with the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native".
>>>
>>>
>>> When the "export NATIVE_PATH=${IMAGES}/../support/test/hotspot/jtreg/native" is used
>>> the log has this line:
>>>
>>> Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/../support/test/hotspot/jtreg/native*/lib*/libException.so' through 'JMXExecutor'
>>>
>>>
>>> Apparently, the sub-directory name "/lib" is added to the path.
>>>
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>>> David
>>>>
>>>> On 16/11/2017 4:34 AM, serguei.spitsyn at oracle.com wrote:
>>>>> Hi Yasumasa and David,
>>>>>
>>>>>
>>>>> On 11/15/17 04:56, David Holmes wrote:
>>>>>> On 15/11/2017 10:15 PM, Yasumasa Suenaga wrote:
>>>>>>> Hi Serguei,
>>>>>>>
>>>>>>>> Do the new tests pass in your runs?
>>>>>>>
>>>>>>> Of course.
>>>>>>> It seems not to exist jtreg native libraries.
>>>>>>> I've tested as below:
>>>>>>>
>>>>>>> $ make build-test-hotspot-jtreg-native
>>>>>>> $ cd test
>>>>>>> $ $JT_HOME/bin/jtreg -ignore:quiet -nativepath:<builddir>/<confdir>/support/test/hotspot/jtreg/native/lib hotspot/jtreg/serviceability/attach hotspot/jtreg/serviceability/dcmd/jvmti jdk/com/sun/tools/attach
>>>>>
>>>>> Thanks.
>>>>> I missed to add the -nativepath flag, sorry.
>>>>>
>>>>>> Please check that:
>>>>>>
>>>>>> make test-image
>>>>>>
>>>>>> followed by jtreg -nativepath:<build-dir>/images/test/hotspot/jtreg/native
>>>>>>
>>>>>> also works.
>>>>>
>>>>> It fails with the error:
>>>>>
>>>>> 63 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so' through 'PidJcmdExecutor'
>>>>> 64 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 28407, JVMTI.agent_load /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg /native/lib/libException.so]'
>>>>> 65 Command returned with exit code 0
>>>>> 66 ---------------- stdout ----------------
>>>>> 67 28407:
>>>>> 68 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so was not loaded.
>>>>> 69 /var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/test/hotspot/jtreg/native/lib/libException.so: cannot open shared object file: No such file or directory
>>>>> 70
>>>>>
>>>>>
>>>>> It seems, the '/lib' folder is added to the nativepath.
>>>>>
>>>>> Yasumasa, could you, double check it please?
>>>>>
>>>>> I'm using the jtreg:
>>>>> /java/re/jtreg/4.2/promoted/latest/binaries/jtreg/bin/jtreg
>>>>>
>>>>> which is:
>>>>>
>>>>> % ls -l /java/re/jtreg/4.2/promoted/latest
>>>>> lrwxrwxrwx 1 uucp 143 7 Nov 6 21:49 /java/re/jtreg/4.2/promoted/latest -> fcs/b10/
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Serguei
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>>
>>>>>>>> Good news is that the attach-related tests from closed repository are passed.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>> On 2017/11/15 16:38, serguei.spitsyn at oracle.com wrote:
>>>>>>>> Hi Yasumasa,
>>>>>>>>
>>>>>>>> Do the new tests pass in your runs?
>>>>>>>>
>>>>>>>> In my runs 3 of 4 tests are failed with the errors like this:
>>>>>>>>
>>>>>>>> 109 Running DCMD 'JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so' through 'PidJcmdExecutor'
>>>>>>>> 110 Executing command '[/var/tmp/sspitsyn/jdk.attach/build/linux-x86_64-normal-server-release/images/jdk/bin/jcmd, 21951, JVMTI.agent_load /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so]'
>>>>>>>> 111 Command returned with exit code 0
>>>>>>>> 112 ---------------- stdout ----------------
>>>>>>>> 113 21951:
>>>>>>>> 114 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so was not loaded.
>>>>>>>> 115 /var/tmp/sspitsyn/tst/jdk.attach/JTwork/scratch/null/lib/libException.so: cannot open shared object file: No such file or directory
>>>>>>>> 116
>>>>>>>>
>>>>>>>>
>>>>>>>> Good news is that the attach-related tests from closed repository are passed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Serguei
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/14/17 16:40, serguei.spitsyn at oracle.com wrote:
>>>>>>>>> Hi Yasumasa,
>>>>>>>>>
>>>>>>>>> It looks good to me.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Serguei
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/7/17 22:38, Yasumasa Suenaga wrote:
>>>>>>>>>> Hi Serguei,
>>>>>>>>>>
>>>>>>>>>> I uploaded new webrev:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.02/
>>>>>>>>>>
>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For
>>>>>>>>>>>>> input string: "apa".
>>>>>>>>>>>>
>>>>>>>>>>>> Should we remove this comparison?
>>>>>>>>>>>
>>>>>>>>>>> I don't understand. Why do remove?
>>>>>>>>>>> Would it better to check for the exception name instead?
>>>>>>>>>> I've changed to check exception name (NumberFormatException) in
>>>>>>>>>> StartManagementAgent.java.
>>>>>>>>>>
>>>>>>>>>>> I will sponsor this fix and run these tests before the push.
>>>>>>>>>> Thanks!
>>>>>>>>>> I'm waiting for second reviewer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yasumasa
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017-11-08 11:55 GMT+09:00 serguei.spitsyn at oracle.com
>>>>>>>>>> <serguei.spitsyn at oracle.com>:
>>>>>>>>>>> On 11/6/17 04:31, Yasumasa Suenaga wrote:
>>>>>>>>>>>> Hi Serguei,
>>>>>>>>>>>>
>>>>>>>>>>>> On 2017/11/06 20:06, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The changes looks good.
>>>>>>>>>>>>> Thank you for making them!
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/3/17 05:10, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>> Hi Serguei,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you for your comment!
>>>>>>>>>>>>>> I uploaded new webrev:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.01/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid
>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) {
>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What is the motivation for this change?
>>>>>>>>>>>>>>> It seems, the original comparison is better.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "ex" is AttachOperationFailedException.
>>>>>>>>>>>>>> We can get the result as below when we run StartManagementAgent:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -------------
>>>>>>>>>>>>>> [runApplication] Error: Invalid com.sun.management.jmxremote.port
>>>>>>>>>>>>>> number: apa
>>>>>>>>>>>>>> [runApplication] jdk.internal.agent.AgentConfigurationError:
>>>>>>>>>>>>>> java.lang.NumberFormatException: For input string: "apa"
>>>>>>>>>>>>>> [runApplication] at
>>>>>>>>>>>>>> jdk.management.agent/sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:336)
>>>>>>>>>>>>>> -------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we should check exception message in
>>>>>>>>>>>>>> AttachOperationFailedException.
>>>>>>>>>>>>>> In fact, jtreg fails at this point in my environment.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd expect a check for some exception name, not for details like: For
>>>>>>>>>>>>> input string: "apa".
>>>>>>>>>>>>
>>>>>>>>>>>> Should we remove this comparison?
>>>>>>>>>>>
>>>>>>>>>>> I don't understand. Why do remove?
>>>>>>>>>>> Would it better to check for the exception name instead?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've tested the following testcases:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - hotspot/jtreg/serviceability/attach
>>>>>>>>>>>>>> - hotspot/jtreg/serviceability/dcmd/jvmti
>>>>>>>>>>>>>> - jdk/com/sun/tools/attach
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are more tests related to dynamic attach in closed,
>>>>>>>>>>>>> nsk.aod.testlist and 30+ attach tests in nsk.jvmti.testlist.
>>>>>>>>>>>>> I'm not sure, if they are included into any of the Mach5 testing levels.
>>>>>>>>>>>>> Will need to check.
>>>>>>>>>>>>> We have to make sure these tests are still passed.
>>>>>>>>>>>>
>>>>>>>>>>>> I cannot access JPRT and closed testcases because I'm not an Oracle
>>>>>>>>>>>> employee.
>>>>>>>>>>>> Can you run them with this change?
>>>>>>>>>>>
>>>>>>>>>>> Ok.
>>>>>>>>>>> I will sponsor this fix and run these tests before the push.
>>>>>>>>>>>
>>>>>>>>>>> It seems, another update and one more review is needed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Serguei
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Serguei
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2017/11/03 16:31, serguei.spitsyn at oracle.com wrote:
>>>>>>>>>>>>>>> Hi Yasumasa,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Some comments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/jdk/com/sun/tools/attach/StartManagementAgent.java.udiff.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - if (!ex.getMessage().contains("Invalid
>>>>>>>>>>>>>>> com.sun.management.jmxremote.port number")) {
>>>>>>>>>>>>>>> + if (!ex.getMessage().contains("For input string: \"apa\"")) {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What is the motivation for this change?
>>>>>>>>>>>>>>> It seems, the original comparison is better.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachException.java.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachIncorrectLibrary.java.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachNoEntry.java.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 37 public void run(CommandExecutor executor) {
>>>>>>>>>>>>>>> 38 try{
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A space is missed after 'try'.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is odd that all test java classes define exactly the same
>>>>>>>>>>>>>>> methods: sharedObjectName(), jmx() and cli().
>>>>>>>>>>>>>>> Would it better to defin a common base class with these methods?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Otherwise, it looks good.
>>>>>>>>>>>>>>> Thank you for taking care about it!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What tests did you run to make sure there are no regressions?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Serguei
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11/1/17 05:59, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>> PING: Could you review and sponsor it?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2017/09/29 13:24, Yasumasa Suenaga wrote:
>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we
>>>>>>>>>>>>>>>>> will get "Command executed successfully". However, it implies error
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> JVMTIAgentLoadDCmd.
>>>>>>>>>>>>>>>>> This message is from JCmd.java when jcmd does not receive any output
>>>>>>>>>>>>>>>>> from target VM.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think HotSopt/jcmd should return useful error message to users to
>>>>>>>>>>>>>>>>> understand the cause of failure.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I uploaded webrev for this issue. Could you review it?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.00/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This change is work fine on Fedora 26 x86_64 as following jtreg
>>>>>>>>>>>>>>>>> testcases:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> - hotspot/jtreg/serviceability/attach
>>>>>>>>>>>>>>>>> - hotspot/jtreg/serviceability/dcmd/jvmti
>>>>>>>>>>>>>>>>> - jdk/com/sun/tools/attach
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I cannot access JPRT. So I need a sponsor.
>>>>>>>>>>>>>>>>> (I cannot test it on other platforms.)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yasumasa
>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
More information about the serviceability-dev
mailing list