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

[Doerr, Martin]

Hi David,

thanks for analyzing it. We need to exclude the test for now.

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
> >