RFR: 8374343: Fix SIGSEGV when lib/modules is unreadable

[Boris Ulasevich]

On Wed, 14 Jan 2026 06:18:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The JVM crashes with a SIGSEGV during startup if the runtime image (lib/modules) exists but is unreadable. In this scenario, ClassLoader::get_jrt_entry() returns nullptr, leading to a crash. This change adds a null check to avoid the dereference and bail out gracefully.
>
> I agree with David's earlier comment. We must limit the amount of system integrity checks. Otherwise, we would need to propagate the failure. So what do we do with this function that calls `ClassLoader::get_jrt_entry()`:
> 
> https://github.com/openjdk/jdk/blob/b082a390b77fca7134000bfe631f73bfd082bfa1/src/hotspot/share/cds/aotClassLocation.cpp#L453-L458
> 
> Do we need to change it to return a boolean to indicate some sort of failure, or do we need to throw a HotSpot exception? In either way, the callers of this function will be affected and soon every function will need to return a boolean or be declared TRAPS.
> 
> In HotSpot, we do the system integrity checks early and exit the VM on failures. For example, we already exit the VM if the modules file is removed from `JAVA_HOME`:
> 
> 
> $ cd images/jdk/lib
> $ mv modules modules.old
> $ ../bin/java 
> Error occurred during initialization of VM
> Failed setting boot class path.
> 
> 
> The same should be done if the modules file is expected to exist but cannot be opened:
> 
> 
> --- a/src/hotspot/share/classfile/classLoader.cpp
> +++ b/src/hotspot/share/classfile/classLoader.cpp
> @@ -1418,6 +1418,10 @@ char* ClassLoader::lookup_vm_options() {
>    jio_snprintf(modules_path, JVM_MAXPATHLEN, "%s%slib%smodules", Arguments::get_java_home(), fileSep, fileSep);
>    JImage_file =(*JImageOpen)(modules_path, &error);
>    if (JImage_file == nullptr) {
> +    if (Arguments::has_jimage()) {
> +      // The modules file exists but is unreadable or corrupt
> +      vm_exit_during_initialization(err_msg("Unable to load %s", modules_path));
> +    }
>      return nullptr;
>    }

@iklam Right. Correct failure propagation here is harder than a simple null check, so an early check and fail-fast behavior seems preferable.

Thanks for the suggestion. I tested it locally and it works well. I’m going to update the PR accordingly.

Do you think it makes sense to add a jtreg regression test to cover lib/modules missing or unreadable cases, or is that unnecessary here?

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

PR Comment: https://git.openjdk.org/jdk/pull/28982#issuecomment-3791328595