[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: Fatal errors when running JCK tests with JDK15/16 debug build
From:       David Holmes <david.holmes () oracle ! com>
Date:       2020-08-31 22:37:11
Message-ID: 80c5c750-2a02-9bd9-d0b4-628481c71264 () oracle ! com
[Download RAW message or body]

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@oracle.com>
>> Sent: Montag, 31. August 2020 04:34
>> To: Doerr, Martin <martin.doerr@sap.com>; serviceability-
>> dev@openjdk.java.net; hotspot-runtime-dev@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
>>>
[prev in list] [next in list] [prev in thread] [next in thread]