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, [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
