JDK-8211723 : AppCDS: referring to a jar file in any way other than exactly how it was done during dumping doesn't work
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9,10,11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-04
  • Updated: 2019-07-07
  • Resolved: 2019-06-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14 b04Fixed
Related Reports
Duplicate :  
JDK-8167546 - enhance os::file_name_strncmp() on Mac OSX
Relates :  
JDK-8226967 - Minimal VM: FALSE was not declared in this scope
Relates :  
JDK-8227370 - Remove SharedPathsMiscInfo
Relates :  
JDK-8207812 - Implement Dynamic CDS Archive
Relates :  
JDK-8167546 - enhance os::file_name_strncmp() on Mac OSX
Description
#1 java -cp hello.jar -Xshare:dump -XX:SharedArchiveFile=my.jsa

#2 java -cp hello.jar -Xshare:on -XX:SharedArchiveFile=my.jsa Hello 

#3 ln -s hello.jar hello2.jar

Referring to the "hello.jar" file in any other way than "hello.jar" doesn't work:

#4 java -cp hello2.jar -Xshare:on -XX:SharedArchiveFile=my.jsa Hello

#5 java -cp ./hello.jar -Xshare:on -XX:SharedArchiveFile=my.jsa Hello

#6 java -cp /Fullpath/hello.jar -Xshare:on -XX:SharedArchiveFile=my.jsa Hello
Comments
Highlight of changes: - the os::file_name_strncmp() and its usages have been removed; - a _from_class_path_attr field of type bool has been added to the ClassPathZipEntry to indicate if the entry is from the ���Class-path��� attribute of a jar file; - FileMapInfo::same_files() has been separated into posix (os_posix.cpp) and windows (os_windows.cpp) versions. - checking of the boot and the app class paths have been moved from SharedPathsMiscInfo::check() to FileMapInfo::validate_shared_path_table(); - for checking the runtime app class paths against the dump time, Arguments::get_appclasspath() is used for getting the runtime app class paths and are stored into an array. The array of runtime app class paths will be checked against the shared_path from the shared archive one by one. If a shared_path is from the ���Class-path��� attribute of a jar file, it will be skipped. The same is being done currently; i.e. we don���t expand the class paths obtained from Arguments::get_appclasspath() if any of the jar refers to other jars by means of the ���Class-path��� attribute. Some sanity checks including file size and modification time is being done currently for all the jars in the shared_path. This remains the same with this change. - boot class paths are being checked in a similar way to app class paths. Some specifics such as the notion of ���relaxed_check��� remains unchanged; - test utilities and new tests.
28-06-2019
@Karen, thanks for the backtrace, which is very helpful. Double checked dynamicArchive.cpp more carefully, it now does following: 905 static void write_archive_info(FileMapInfo* dynamic_info, DynamicArchiveHeader *header) { 906 dynamic_info->write_header(); ... The 'misc' path info is being written out now. So that does address my concern regarding the ordering issue.
27-04-2019
@Jiangli 2019-01-18: Thank you for the detailed description for your concern that this was a bug for the dynamic archive. I wanted to follow up on your concern that the dynamic archive does not do the separate runtime path check using os::file_name_strncmp(), but just does the validate_shared_path_table. I do not know what the code looked like in January. As of April 26, 2019 in this webrev: http://cr.openjdk.java.net/~ccheung/8207812_dynamic_cds_archive/webrev.00/src/hotspot/share/memory/dynamicArchive.cpp.html this appears to be doing both checks as you suggested. Here is the code path to the os::file_name_strncmp() call. MetaspaceShared::initialize_runtime_shared_and_meta_spaces FileMapInfo* = new FileMapInfo(true) mapinfo->initialize() initialize_dynamic_runtime_shared_spaces(...) DynamicArchive::map() mapinfo = new FileMapInfo(false) map_impl(mapinfo) DynamicArchive::map_info(mapinfo) FileMapInfo:initialize takes bool (is_static) FileMapInfo::validate_header(is_static) ClassLoader::check_shared_paths_misc_info (... is_static) SharePathsMiscInfo checker::check(is_static) check(type, path, is_static) same os::file_name_strcmp Given that call sequence, I think your concern about a bug in the dynamic archive implementation has been met. That should give us the ability to implement your recommendations for relaxing the restrictions as a follow-on RFE with less urgency.
26-04-2019
After discussion with [~iklam], we don't think this is a blocker for JDK-8207812. The existing class paths check is in place for dynamic archive. This RFE will be done after the first integration of JDK-8207812.
01-02-2019
I think when Gerard reported this problem we thought it might be a mac only issue. It turns out to be a generic issue. Reassigned to Calvin @ CDS team.
18-01-2019
The dynamic archive does not do a separate runtime path check using the os::file_name_strncmp(). The checks are done using the shared path table. The suggested fix in the above will add the path ordering check "to ensure the ordering of the runtime paths is the same as the dump time paths and also to make sure there is no new path component added in front any of the dump time existing path components". That ordering check should be integrated first and tested with the dynamic archive.
18-01-2019
Why is this a blocker for JDK-8207812? That RFE is for creating a CDS archive dynamically. This RFE is for relaxing the classpath checks. They seem to be independent issues.
18-01-2019
Since this is a blocker for JDK-8207812, which is targeted for JDK 13, [~gziemski] or [~mseledtsov] could you please targeting this to 13? Thanks.
18-01-2019
We can remove the separate runtime path check using the os::file_name_strncmp() call in classfile/sharedPathsMiscInfo.cpp. The reason for the check is to ensure the ordering of the runtime paths is the same as the dump time paths and also to make sure there is no new path component added in front any of the dump time existing path components. Then we can also remove the problematic os::file_name_strncmp(). We should instead do the ordering check in FileMapInfo::validate_shared_path_table(). FileMapInfo::validate_shared_path_table() iterates through the recorded shared path table and validates each dump time path. To include the ordering check here, we can get the runtime class_path using Arguments::get_appclasspath() and compare each runtime class_path component in canonical form with the recorded shared table element. Benefits of this approach: 1.More efficient than doing two separate checks 2.Help clean up the code 3.Lift some of the current restrictions imposed by the os::file_name_strncmp() check. It would allow us to support more cases with valid runtime path usage but rejected by the os::file_name_strncmp() check. For example the mixed usages of absolute path and relative path at runtime and dump time. Usage of symbolic link to file would also be allowed.
25-10-2018
We can use os::Posix::realpath() API to implement the path resolution.
22-10-2018
I think that all the issues would go away if at the time we dump the archive we fully resolve the jar path and store that absolute path. Then later when we actually run we again fully resolve the paths and compare those.
05-10-2018
This is a path validation issue specifically related to AppCDS when application classes are included in the shared archive. AppCDS performs class path compatibility checks for boot append path, and -classpath at runtime when application classes present in the archive. The path check does rigid path string comparison. We should investigate how to improve and relax the path validation with AppCDS.
05-10-2018