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.spit...@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
