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
