RFR(S): JDK-8143921 nsk/jdi/ObjectReference/waitingThreads/waitingthreads003 fails with JVMTI_ERROR_INVALID_CLASS

[serguei.spitsyn at oracle.com]

Dmitry,

Thank you for the reply.
I hope, you run all the JDI tests including nsk.jdi and jtreg com/sun/jdi.

Reviewed.

Thanks,
Serguei


On 4/20/16 10:12, Dmitry Samersoff wrote:
> Serguei,
>
> The test fails rarely and I'm not able to reproduce the issue.
>
> JDWP call JvmtiGetLoadedClasses::getLoadedClasses then store received
> classes locally.
>
> So nothing prevent these classes from being unloaded and I think it's
> worth to fix.
>
> -Dmitry
>
> On 2016-04-19 19:49, serguei.spitsyn at oracle.com wrote:
>> On 4/19/16 09:42, serguei.spitsyn at oracle.com wrote:
>>> Hi Dmitry,
>>>
>>> 144 // Clazz become invalid since the time we get the class list
>>> 145 // Skip this entry
>>> 146 if (error == JVMTI_ERROR_INVALID_CLASS) {
>>> 147 continue;
>>> 148 }
>>> 149
>>> I'd like to better understand the root cause of this issue.
>>> Could you, please, give an idea why a class in this test becomes invalid?
>>> Do you think there is a potential in this test for a class to get
>>> unloaded?
>>> Or is it something about anonymous classes?
>> One more question:
>>    Any ideas on why these two tests started failing in November 2015 and
>> did not fail before?
>>
>>
>> Thanks,
>> Serguei
>>
>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 4/19/16 06:56, Dmitry Samersoff wrote:
>>>> Any reviewers?
>>>>
>>>> On 2016-04-13 19:24, Dmitry Samersoff wrote:
>>>>> Everybody.
>>>>>
>>>>> Please review a small fix.
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8143921/webrev.01/
>>>>>
>>>>> I don't have a reproducer, so the fix is based on coredump analyzes.
>>>>>
>>>>> Tested with rbt
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>