[Bug]: JPDFium native library fails to load in Debian 13 LXC due to executable stack requirement

[MickLesk]

Installation Method

Local Installation

The Problem

Merge/Split fails in an unprivileged Debian 13 LXC container after upgrading Stirling-PDF past v2.11.0.

This is related to the new JPDFium/native PDFium backend introduced in v2.12.0+. The bundled native library fails to load inside LXC because one of the extracted native libraries requires an executable stack.

Reference downstream issue in community-scripts:

community-scripts/ProxmoxVE#15513

The affected install is deployed as a bare .jar via systemd, not Docker.

Version of Stirling-PDF

v2.14.0

Last Working Version of Stirling-PDF

v.2.10.x

Page Where the Problem Occurred

Merge PDFs / Split PDFs

Docker Configuration

Not Docker.

Local installation inside Debian 13 LXC on Proxmox VE 9.2.3.

Relevant Log Output

Caused by: java.lang.UnsatisfiedLinkError: /tmp/jpdfium-/libjpdfium.so: libicudata.so.74: cannot enable executable stack as shared object requires: Invalid argument at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:321) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2245) at java.base/java.lang.Runtime.load0(Runtime.java:767) at java.base/java.lang.System.load(System.java:1647) at stirling.software.jpdfium.panama.NativeLoader.tryLoadFromClasspath(NativeLoader.java:103) at stirling.software.jpdfium.panama.NativeLoader.ensureLoaded(NativeLoader.java:30) Caused by: stirling.software.jpdfium.exception.NativeLoadException: Failed to load native library at stirling.software.jpdfium.panama.NativeLoader.ensureLoaded(NativeLoader.java:44) at stirling.software.jpdfium.panama.JpdfiumLib.<init>(JpdfiumLib.java:45) at stirling.software.jpdfium.PdfDocument.open(PdfDocument.java:31) at stirling.software.SPDF.controller.api.MergeController.mergePdfs(MergeController.java:307)


readelf -lW confirms that the affected native library has an executable stack requirement:

GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

Additional Information

This is reproducible on a fresh Debian 13 LXC installation.

Downstream we tried patching system ICU libraries during installation:

msg_info "Patching Native Libraries for LXC Compatibility"
ensure_dependencies patchelf
find /usr/lib -name "libicudata.so.*" -exec patchelf --clear-execstack {} \; || true
msg_ok "Patched Native Libraries"

however, fresh installs still fail because the problematic native library is bundled/extracted by JPDFium at runtime, so patching system libraries is not sufficient.

The issue does not appear to be caused by missing dependencies. ldd resolves the native library dependencies cleanly.

Also tested:
GLIBC_TUNABLES=glibc.cpu.hwcaps=-SHSTK

This did not resolve the issue.
This looks like an upstream packaging/build problem in the bundled native JPDFium/PDFium library. Ideally, the native library should be shipped without requiring an executable stack, or JPDFium should provide a container-compatible build.

Browsers Affected

Other

No Duplicate of the Issue

• I have verified that there are no existing issues raised related to my problem.

[dosubot]

This is a confirmed issue that was also reported in #6647 by another user running v2.13.1 as a bare .jar on Debian 13 x64 with the identical libicudata.so.74: cannot enable executable stack error [1].

The Docker ultra-lite variant of this problem was fixed in PR #6706 (switching to a glibc-based image and bundling per-arch JPDFium natives), but the bare JAR deployment case on LXC/Debian remains unresolved. The maintainer acknowledged that JAR deployments "require custom working based on the OS they are running on" and the current focus has been Docker-first [1].

The root cause is as you identified — JPDFium's bundled libicudata.so.74 has the GNU_STACK RWE flag, and modern kernels (especially in unprivileged LXC containers) refuse to load shared objects requiring an executable stack. Since the library is extracted at runtime to /tmp/jpdfium-*/, patching system ICU libraries doesn't help.

Current workarounds:

• Downgrade to v2.10.x/v2.11.0 (last version before JPDFium was used for merge)
• Switch to Docker deployment (the official Docker images include the proper native setup)

As a potential interim hack (untested), you could try patching the extracted library after it's written to /tmp:

# After Stirling-PDF starts and extracts natives:
find /tmp -path "*/jpdfium-*/libicudata.so*" -exec patchelf --clear-execstack {} \;

...but this is fragile since the extraction happens on first use and the path includes a random suffix.

You're right that the proper fix is upstream in the JPDFium build — the native library should be compiled/linked without requiring an executable stack (-z noexecstack linker flag or equivalent).

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.