David,
It looks good.
Thanks,
Serguei
On 5/24/16 22:05, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8154589
webrev: http://cr.openjdk.java.net/~dholmes/8154589/webrev/
We sometimes see tests failing with a VM assertion failure that a
klass was not loaded (the actual assertion message is wrong):
# assert(k != NULL) failed: preloaded klass not initialized
Stack: [0xfffffd7fa80ff000,0xfffffd7fa81ff000], sp=0xfffffd7fa81fc570,
free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
V [libjvm.so+0x2a01a57] void VMError::report(outputStream*)+0x937
V [libjvm.so+0x2a02e4b] void VMError::report_and_die()+0x55f
V [libjvm.so+0x10b670b] void report_vm_error(const char*,int,const
char*,const char*)+0x55f
V [libjvm.so+0x28937e5] void
ConcurrentLocksDump::dump_at_safepoint()+0x43d
V [libjvm.so+0x287ab7e] void
Threads::print_on(outputStream*,bool,bool,bool)+0xcce
V [libjvm.so+0x2a372a7] void VM_PrintThreads::doit()+0x1b
V [libjvm.so+0x2a366e9] void VM_Operation::evaluate()+0xc5
In a few of the VMOperation doit_prologue methods we have this logic
to ensure the AOS class is loaded:
java_util_concurrent_locks_AbstractOwnableSynchronizer::initialize(JavaThread::current());
but we don't check if the class actually was successfully loaded! We
may have an exception pending due to OOME for example. Because the
prologue returns true, the VMOp is posted for the VMThread to execute
and when doit() accesses the class that was presumed loaded by the
prologue we get NULL and hit the assertion.
Simple fix is to just return false if an exception is pending.
Testing: jprt, tmtools tests (in progress)
Thanks,
David