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

[David Holmes]

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
>