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

[David Holmes]

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