PING: RFR: 8165736: Error message should be shown when JVMTI agent cannot be attached
David Holmes
david.holmes at oracle.com
Thu Nov 16 02:11:15 UTC 2017
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
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