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

David Holmes david.holmes at oracle.com
Wed Sep 16 01:52:26 UTC 2020


Hi Coleen,

On 15/09/2020 10:19 pm, Coleen Phillimore wrote:
> 
> The string in these tests are a legal utf8 but still fail conversion, 

The problem is that it expects string A and gets string B - which 
suggests that thread-safety problem still exists somehow:

fatal error: String conversion failure: [check] ExitLock destroyed
-->    [check] ExitLock exited

David
-----

> which is unexpected.  I'll have a look.
> 
> + if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, 
> (int)strlen(utf8_str), false)) {
> ResourceMark rm;
> const char* expected = utf8_str;
> char* actual = as_utf8_string(h_obj());
> if (strcmp(expected, actual) != 0) {
> - tty->print_cr("String conversion failure: %s --> %s", expected, actual);
> - ShouldNotReachHere();
> + fatal("String conversion failure: %s --> %s", expected, actual);
> }
> }
> 
> 
> Thanks,
> Coleen
> 
> On 9/15/20 3:44 AM, Doerr, Martin wrote:
>>
>> Hi Leonid,
>>
>> I don’t have access to JCK issues, but thanks for creating it.
>>
>> Best regards,
>>
>> Martin
>>
>> *From:*leonid.kuskov at oracle.com <leonid.kuskov at oracle.com>
>> *Sent:* Montag, 14. September 2020 23:00
>> *To:* Doerr, Martin <martin.doerr at sap.com>; David Holmes 
>> <david.holmes at oracle.com>; serviceability-dev at openjdk.java.net; 
>> hotspot-runtime-dev at openjdk.java.net
>> *Cc:* Zeller, Arno <arno.zeller at sap.com>
>> *Subject:* Re: Fatal errors when running JCK tests with JDK15/16 debug 
>> build
>>
>> Hi Martin,
>>
>> This issue looks rather a test problem. I've filled the ticket 
>> JCK-7314897 <https://bugs.openjdk.java.net/browse/JCK-7314897>.
>>
>> Best Regards,
>> Leonid
>>
>> On 9/7/20 3:23 AM, Doerr, Martin wrote:
>>
>>     Hi Leonid,
>>
>>     the errors were observed in many more vm/jvmti/Get... tests like the following ones:
>>
>>     vm/jvmti/GetAllThreads/gath001/gath00101/gath00101.html
>>
>>     vm/jvmti/GetAvailableProcessors/gaps001/gaps00101/gaps00101.html
>>
>>     vm/jvmti/GetClassModifiers/gcmo001/gcmo00102/gcmo00102.html
>>
>>     vm/jvmti/GetClassMethods/gcmt001/gcmt00102/gcmt00102.html
>>
>>     vm/jvmti/GetBytecodes/gbyc001/gbyc00102/gbyc00102.html
>>
>>     vm/jvmti/GetCapabilities/gcap001/gcap00101/gcap00101.html
>>
>>     vm/jvmti/GetClassLoader/gclo001/gclo00101/gclo00101.html
>>
>>     We run them with fastdbg builds every night and we have seen the errors almost every day.
>>
>>     Best regards,
>>
>>     Martin
>>
>>         -----Original Message-----
>>
>>         From: David Holmes<david.holmes at oracle.com>  <mailto:david.holmes at oracle.com>
>>
>>         Sent: Dienstag, 1. September 2020 07:07
>>
>>         To:leonid.kuskov at oracle.com  <mailto:leonid.kuskov at oracle.com>; Doerr, Martin<martin.doerr at sap.com>  <mailto:martin.doerr at sap.com>;
>>
>>         serviceability-dev at openjdk.java.net  <mailto:serviceability-dev at openjdk.java.net>; hotspot-runtime-
>>
>>         dev at openjdk.java.net  <mailto:dev at openjdk.java.net>
>>
>>         Subject: Re: Fatal errors when running JCK tests with JDK15/16 debug build
>>
>>         Hi Leonid,
>>
>>         On 1/09/2020 10:42 am,leonid.kuskov at oracle.com  <mailto:leonid.kuskov at oracle.com>  wrote:
>>
>>             Hi,
>>
>>             It's a known issue that was reported by Arno Zeller
>>
>>             (arno.zeller at sap.com  <mailto: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>  <mailto:david.holmes at oracle.com>
>>
>>                         Sent: Montag, 31. August 2020 04:34
>>
>>                         To: Doerr, Martin<martin.doerr at sap.com>  <mailto:martin.doerr at sap.com>; serviceability-
>>
>>                         dev at openjdk.java.net  <mailto:dev at openjdk.java.net>;hotspot-runtime-dev at openjdk.java.net  <mailto: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
>>
> 


More information about the serviceability-dev mailing list