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]>
Sent: Dienstag, 1. September 2020 07:07
To: [email protected]; Doerr, Martin <[email protected]>;
[email protected]; hotspot-runtime-
[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] wrote:
Hi,
It's a known issue that was reported by Arno Zeller
([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]>
Sent: Montag, 31. August 2020 04:34
To: Doerr, Martin <[email protected]>; serviceability-
[email protected]; [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
