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

Tue Sep 15 07:44:15 UTC 2020

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