Hi Leonid, the errors were observed in many more vm/jvmti/Get... tests like the following ones:
vm/jvmti/GetAllThreads/gath001/gath00101/gath00101.html vm/jvmti/GetAvailableProcessors/gaps001/gaps00101/gaps00101.html vm/jvmti/GetClassModifiers/gcmo001/gcmo00102/gcmo00102.html vm/jvmti/GetClassMethods/gcmt001/gcmt00102/gcmt00102.html vm/jvmti/GetBytecodes/gbyc001/gbyc00102/gbyc00102.html vm/jvmti/GetCapabilities/gcap001/gcap00101/gcap00101.html vm/jvmti/GetClassLoader/gclo001/gclo00101/gclo00101.html We run them with fastdbg builds every night and we have seen the errors almost every day. Best regards, Martin > -----Original Message----- > From: David Holmes <[email protected]> > Sent: Dienstag, 1. September 2020 07:07 > To: [email protected]; Doerr, Martin <[email protected]>; > [email protected]; hotspot-runtime- > [email protected] > Subject: Re: Fatal errors when running JCK tests with JDK15/16 debug build > > Hi Leonid, > > On 1/09/2020 10:42 am, [email protected] wrote: > > Hi, > > > > It's a known issue that was reported by Arno Zeller > > ([email protected]) in the middle of June. The test > > jvmti/GetAllStackTraces/gast001/gast00105/gast00105.html failed with the > > same stack trace despite the fix ( JCK-7022500 lprintf in > > jvmti/support.c is not MT-Safe) Please file a JCK's issue with details > > to reproduce the failure. > > Interesting. The fix is supposed to make things thread-safe by using a > RawMonitor to ensure only one thread can use lprintf at a time. I missed > that in my initial analysis. But something is going wrong. > > Thanks, > David > > > Thanks, > > Leonid > > > > On 8/31/20 3:37 PM, David Holmes wrote: > > > >> On 1/09/2020 3:00 am, Doerr, Martin wrote: > >>> Hi David, > >>> > >>> thanks for analyzing it. We need to exclude the test for now. > >> > >> Can you file a JCK bug? I can file one on our internal JCK Jira but > >> I'm not sure what the right process is in this case. > >> > >> Thanks, > >> David > >> > >>> 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 > >>>>>
