RFR: 8299329: Assertion failure with fastdebug build when trying to use CDS without classpath [v5]

Ashutosh Mehra duke at openjdk.org
Thu Jan 5 14:55:51 UTC 2023


On Thu, 5 Jan 2023 03:09:16 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

>> It appears longest_common_app_classpath_prefix_len() is not returning correct value when there is no file separator in the path being searched backwards. Instead of returning 0 it return 1.
>> 
>> In case of empty classpath, it can result in assertion failure in check_paths():
>> 
>> `assert(strlen(rp_array->at(i)) > (size_t)runtime_prefix_len, "sanity");`
>> 
>> It can also result in incorrectly validating the app classpaths if they only differ by first character. Eg:
>> 
>> Dump time:
>>   -cp hello.jar
>> Run time:
>>   -cp mello.jar
>> 
>> This would not result in classpath mismatch!
>> 
>> This fix updates longest_common_app_classpath_prefix_len() to return 0 if no file separator character is found.
>> 
>> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add spaces
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

There is a test failure on macos-x64 not related to the changes in this PR.
The test `test/hotspot/jtreg/gc/g1/TestVerifyGCType.java` fails at:


java.lang.RuntimeException: Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
	at gc.g1.TestVerifyGCType.verifyType(TestVerifyGCType.java:201)
	at gc.g1.TestVerifyGCType.verifyCollection(TestVerifyGCType.java:196)
	at gc.g1.TestVerifyGCType.testYoungEvacFail(TestVerifyGCType.java:134)
	at gc.g1.TestVerifyGCType.main(TestVerifyGCType.java:57)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1623)


Looks like this is same as [JDK-8298215](https://bugs.openjdk.org/browse/JDK-8298215) which is already fixed. I guess the branch is not up-to-date and doesn't have the required fix, which is why this test failed. I think the failure can be ignored.

-------------

PR: https://git.openjdk.org/jdk/pull/11781


More information about the hotspot-runtime-dev mailing list