Fatal errors when running JCK tests with JDK15/16 debug build

[Doerr, Martin]

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 <david.holmes at oracle.com>
> Sent: Dienstag, 1. September 2020 07:07
> To: leonid.kuskov at oracle.com; Doerr, Martin <martin.doerr at sap.com>;
> serviceability-dev at openjdk.java.net; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: Fatal errors when running JCK tests with JDK15/16 debug build
> 
> Hi Leonid,
> 
> On 1/09/2020 10:42 am, leonid.kuskov at oracle.com wrote:
> > Hi,
> >
> > It's a known issue that was reported by Arno Zeller
> > (arno.zeller at sap.com) 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 <david.holmes at oracle.com>
> >>>> Sent: Montag, 31. August 2020 04:34
> >>>> To: Doerr, Martin <martin.doerr at sap.com>; serviceability-
> >>>> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> >>>> 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
> >>>>>