Hi David, thanks for analyzing it. We need to exclude the test for now.
Best regards, Martin > -----Original Message----- > From: David Holmes <[email protected]> > Sent: Montag, 31. August 2020 04:34 > To: Doerr, Martin <[email protected]>; serviceability- > [email protected]; [email protected] > Subject: Re: Fatal errors when running JCK tests with JDK15/16 debug build > > Hi Martin, > > On 29/08/2020 3:53 am, Doerr, Martin wrote: > > Hi, > > > > we have seen the following fatal error more than 50 times since > > 2020-05-25 in various JCK tests vm/jvmti. > > > > fatal error: String conversion failure: [check] ExitLock destroyed > > > > --> [check] ExitLock exited > > > > (followed by garbage output) > > > > 8166358: Re-enable String verification in > > java_lang_String::create_from_str() > > > > was pushed at that date which introduced the call to fatal. > > > > Stack (example from linuxppc64le, but also observed on x86 and aarch64): > > V [libjvm.so+0xee242c] java_lang_String::create_from_str(char const*, > > Thread*) [clone .part.158]+0x51c > > V [libjvm.so+0xee2530] java_lang_String::create_oop_from_str(char > > const*, Thread*)+0x40 > > V [libjvm.so+0x1026a30] jni_NewStringUTF+0x1e0 > > C [libjckjvmti.so+0x3ce4c] logWrite+0x5c > > C [libjckjvmti.so+0x3cd20] lprintf+0x170 > > C [libjckjvmti.so+0x485b8] gast00104_agent_proc+0x254 > > V [libjvm.so+0x1218f0c] JvmtiAgentThread::call_start_function()+0x24c > > V [libjvm.so+0x193a8fc] JavaThread::thread_main_inner()+0x32c > > V [libjvm.so+0x19418a0] Thread::call_run()+0x160 > > V [libjvm.so+0x15c9d0c] thread_native_entry(Thread*)+0x18c > > C [libpthread.so.0+0x9b48] start_thread+0x108 > > > > (Problem could have been there before but without this fatal message.) > > > > The messages are generated by: > > > > tests/vm/jvmti/GetAllStackTraces/gast001/gast00104/gast00104.c > > > > This looks like a race condition. The message changes while the VM > > creates a String object from it. Has anybody seen this before? > > No but ... > > > Is it a test problem? I'm not familiar with the lprintf calls in the test. > > ... the lprintf is part of the JCK support library (support.c if you > have access to sources) and it uses a static buffer for the log messages > and so it not thread-safe. This test creates a thread and both it and > the main thread call lprintf concurrently. > > So this is a JCK test/test-library bug that appears to be exposed by the > changes made in 8166358. > > Cheers, > David > ----- > > > Best regards, > > > > Martin > >
