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

[Coleen Phillimore]

Hi I thought I reported this.  I reenabled the assert that you're 
hitting.  One of the JCK tests is passing junk to JNI. I don't know why 
our tests aren't failing this though.
Coleen

On 9/1/20 1:06 AM, David Holmes wrote:
> 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
>>>>>>