Fatal errors when running JCK tests with JDK15/16 debug build
Coleen Phillimore
coleen.phillimore at oracle.com
Tue Sep 15 12:19:20 UTC 2020
The string in these tests are a legal utf8 but still fail conversion,
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:*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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200915/becdcd45/attachment-0001.htm>
More information about the serviceability-dev
mailing list