Fatal errors when running JCK tests with JDK15/16 debug build
Doerr, Martin
martin.doerr at sap.com
Mon Aug 31 17:00:10 UTC 2020
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
> >
More information about the hotspot-runtime-dev
mailing list