RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError

[Chris Plummer]

Hi Alex,

Good catch. I guess it doesn't blow up because we only enable the two 
callbacks we setup. It looks like we usually zero it out with:

     memset(&callbacks, 0, sizeof(callbacks));

So I'll go with that fix.

thanks,

Chris

On 12/6/17 4:48 PM, Alex Menkov wrote:
> +1
>
> Chris, while you are there could you please fix a minor issue with the 
> native part of the test - Agent_Initialize doesn't zero callbacks 
> struct (only sets MonitorContendedEnter/MonitorContendedEntered):
>
> -    jvmtiEventCallbacks callbacks;
> +    jvmtiEventCallbacks callbacks = {0};
>
> --alex
>
> On 12/06/2017 15:33, serguei.spitsyn at oracle.com wrote:
>> Hi Chris,
>>
>> It looks good to me.
>> I wonder if we have other similar cases like this in the JVMTI tests.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 12/6/17 14:38, Chris Plummer wrote:
>>> Hello,
>>>
>>> Please review the following:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8191229
>>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/
>>>
>>> The test is testing contended monitor support. After registering the 
>>> callback, it gets an unexpected notification of a contended monitor, 
>>> which is happening while the finalizer thread is running. In the 
>>> callback the test does a FindClass to find a test class, but the 
>>> classloader context is not correct when the finalizer thread is 
>>> current, so FindClass fails and leaves an exception pending 
>>> (probably blowing away the finalzer thread) and also (separately) 
>>> causes the test to fail. It's unknown why this callback is suddenly 
>>> being triggered, but the callback itself is not a bug, and the test 
>>> needs to defend against it.
>>>
>>> The fix is to lookup the test class during test initialization and 
>>> keep it cached, rather than look it up every time there is a 
>>> contended monitor callback.
>>>
>>> thanks,
>>>
>>> Chris
>>