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

Tue, 15 Sep 2020 18:53:41 -0700 

Hi Coleen,

On 15/09/2020 10:19 pm, Coleen Phillimore wrote:



The string in these tests are a legal utf8 but still fail conversion, 



The problem is that it expects string A and gets string B - which 
suggests that thread-safety problem still exists somehow:


fatal error: String conversion failure: [check] ExitLock destroyed
-->    [check] ExitLock exited

David
-----


which is unexpected.  I'll have a look.


+ if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, 
(int)strlen(utf8_str), false)) {

ResourceMark rm;
const char* expected = utf8_str;
char* actual = as_utf8_string(h_obj());
if (strcmp(expected, actual) != 0) {
- tty->print_cr("String conversion failure: %s --> %s", expected, actual);
- ShouldNotReachHere();
+ fatal("String conversion failure: %s --> %s", expected, actual);
}
}


Thanks,
Coleen

On 9/15/20 3:44 AM, Doerr, Martin wrote:


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


























					Reply via email to