Hi Leonid, I don’t have access to JCK issues, but thanks for creating it.
Best regards, Martin From: [email protected] <[email protected]> Sent: Montag, 14. September 2020 23:00 To: Doerr, Martin <[email protected]>; David Holmes <[email protected]>; [email protected]; [email protected] Cc: Zeller, Arno <[email protected]> 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 <[email protected]><mailto:[email protected]> Sent: Dienstag, 1. September 2020 07:07 To: [email protected]<mailto:[email protected]>; Doerr, Martin <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]>; hotspot-runtime- [email protected]<mailto:[email protected]> Subject: Re: Fatal errors when running JCK tests with JDK15/16 debug build Hi Leonid, On 1/09/2020 10:42 am, [email protected]<mailto:[email protected]> wrote: Hi, It's a known issue that was reported by Arno Zeller ([email protected]<mailto:[email protected]>) 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 <[email protected]><mailto:[email protected]> Sent: Montag, 31. August 2020 04:34 To: Doerr, Martin <[email protected]><mailto:[email protected]>; serviceability- [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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
