PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Thu Nov 16 07:49:42 UTC 2017
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