On Tue, 16 Jun 2026 13:28:43 GMT, Arno Zeller <[email protected]> wrote:

> When jlink --strip-debug (or --strip-native-debug-symbols 
> exclude-debuginfo-files) is used to link from a runtime image, pre-existing 
> native debug symbol sidecar files (.debuginfo, .diz) are incorrectly included 
> in the output image. On a JDK built with external debug symbols, this results 
> in large files such as lib/server/libjvm.debuginfo (often 1 GB) appearing in 
> the linked image despite the explicit request to strip debug information.
> 
> StripNativeDebugSymbolsPlugin.transform() only processes entries whose path 
> ends in .so (NATIVE_LIB) or whose type is NATIVE_CMD. Sidecar files have type 
> NATIVE_LIB or NATIVE_CMD but paths ending in .debuginfo or .diz (compressed 
> .debuginfo), so they fall through the filter unchanged.
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

Yes, `strip-native-debug-symbols` should do what it [says on the 
tin](https://bugs.openjdk.org/browse/JDK-8219257). With this patch it also 
filters files which is a) unspecified b) might filter a file a user doesn't 
expect it to.

I believe adding the extra filter to the default `jpackage` `jlink` options 
seems the reasonable approach. It's fairly unlikely that JMODs would actually 
include external debug symbols in separate files. Therefore, the risk of adding 
that extra filter is low (as most builds won't include such files anyway). The 
CSR/release note would document this behaviour.

The JDK builds affected in practise don't seem very common and we could also 
consider fixing the tests in question to not use the default jlink options and 
add the `--exclude-files` there.

> But, maybe it would be an idea to handle the file filtering in 
> [DefaultStripDebugPlugin.java](https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultStripDebugPlugin.java)
>  by calling the `--exclude-files` plugin there and then also filter out debug 
> files on Windows and MacOS.

I'm fine with that if desired. It's also a behavioural change and would require 
a CSR similar to the one we did with 
[JDK-8214796](https://bugs.openjdk.org/browse/JDK-8219257).

This isn't a bug in StripNativeDebugSymbols plugin.

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

PR Comment: https://git.openjdk.org/jdk/pull/31534#issuecomment-4752509055

Reply via email to