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

[leonid.kuskov at oracle.com]

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.

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