RFR:8148103:add more tests for task "Update JDI and JDWP for modules"

[serguei.spitsyn at oracle.com]

Alexander,

The objectID size (and so, the moduleID size) must be always 8 bytes.

I think, the following fragments have errors:

JdwpCmd.java

   80     protected void putRefId(long refId) {
   81         if (Arch.is64()) {
   82             data.putLong(refId);
   83         } else {
   84             data.putInt((int) refId);
   85         }
   86     }


JdwpReply.java

   70     protected long readRefId(DataInputStream ds) throws IOException {
   71         if (Arch.is64()) {
   72             return ds.readLong();
   73         } else {
   74             return ds.readInt();
   75         }
   76     }


In both cases the ds.readLong() must be returned independently of the Arch.is64().

Thanks,
Serguei




On 8/25/16 10:42, serguei.spitsyn at oracle.com wrote:
> Hi Alexander,
>
> The error code 42 is INVALID_MODULE:
> *INVALID_MODULE*
> 	
> 42
> 	
> Invalid module.
>
>
> It means that the moduleID passed to the JDWP is not correct.
> So that we have to check if the moduleID format is correct for 32-bit.
>
>
> The moduleID type is specified as:
> *moduleID*
> 	
>  same as objectID
> 	
>  Uniquely identifies an object in the target VM that is known to be a 
> module object.
>
>
>
> The size of objectID is returned by the ViltualMachine(1) command 
> IDSizes(7):
> Reply Data
>
>     	
>     	
>     	
>     	
>     	
>     	
>     int 	/fieldIDSize/ 	fieldID size in bytes
>     int 	/methodIDSize/ 	methodID size in bytes
>     int 	/objectIDSize/ 	objectID size in bytes
>     int 	/referenceTypeIDSize/ 	referenceTypeID size in bytes
>     int 	/frameIDSize/ 	frameID size in bytes
>
>
>
> Please, let me know what you think.
>
> Thanks,
> Serguei
>
>
>
> On 8/25/16 04:56, Alexander Kulyakhtin wrote:
>> Hi Sergey,
>>
>> Most unfortunately, the test is failing on 32-bit machines only withhttps://bugs.openjdk.java.net/browse/JDK-8164490.
>>
>> It may well be a test issue, so I appreciate your looking at the test source. I was not able to locate any issue with the test and it runs fine on 64-bit machines.
>> Perhaps, it has to do with any difference in JDWP strings representation on 32/64 machines?
>>
>> Best regards,
>> Alexander
>>   
>> ----- Original Message -----
>> From:serguei.spitsyn at oracle.com
>> To:alexander.kulyakhtin at oracle.com,serviceability-dev at openjdk.java.net
>> Cc:christian.tornqvist at oracle.com
>> Sent: Wednesday, August 24, 2016 11:22:23 PM GMT +03:00 Iraq
>> Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules"
>>
>> Hi Alexander,
>>
>> It is great that you developed a test coverage for this feature.
>> Just wanted to let you know that I'm reviewing your fix now.
>> Did you get any other reviews yet?
>>
>> Thanks,
>> Serguei
>>
>>
>> On 8/12/16 05:55, Alexander Kulyakhtin wrote:
>>> Hi,
>>>
>>> Could you, please, review the following test-only change (adding a new test):
>>>
>>> CR:https://bugs.openjdk.java.net/browse/JDK-8148103
>>> Webrev:http://cr.openjdk.java.net/~akulyakh/8148103_02/
>>>
>>> The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead.
>>>
>>> It does so by launching a debuggee java program  with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test.
>>>
>>> When started the debuggee reports its loaded modules to the test.
>>> The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP.
>>> For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API.
>>> Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct.
>>>
>>> Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test.
>>> The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner.
>>>
>>> Best regards,
>>> Alexander
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160825/c97c98b5/attachment.html>