SIGSEGV Crash During Excel to PDF Conversion with Images on Linux Debian Server (OEM License) — Works Flawlessly on Windows

We are experiencing a critical SEGMENTATION FAULT (SIGSEGV) when converting Excel files containing embedded images to PDF using Aspose.Cells for Node.js with an OEM license. The application crashes during the NAPI cleanup phase after successful PDF generation.

Critical Details:

  • :white_check_mark: Works perfectly on Windows (local development)
  • :x: Crashes on Linux Debian (production server)
  • :white_check_mark: Works fine with Excel files without images
  • :x: Fails specifically with image-heavy Excel files

ENVIRONMENT DETAILS

Local Development (Working Perfectly):

OS: Windows 10/11
Node.js: LTS
aspose.cells.node: ^25.12.0
License: OEM (Aspose.CellsforNode.jsviaC++OEM.lic)
Execution: Synchronous PDF conversion with watermarking
Architecture: x64
Status: :white_check_mark: No issues, handles images without problems

Production Environment (Failing):

OS: Linux (Debian 11/12)
Container: Docker
Node.js: 22 (node:22 base image)
aspose.cells.node: ^25.12.0
License: OEM (same as local - Aspose.CellsforNode.jsviaC++OEM.lic)
Deployment: Kubernetes cluster
Architecture: x64
Status: :x: SIGSEGV crash with image-containing Excel files

Docker Configuration:

FROM node:22

WORKDIR /app

Dependencies are minimal - no special image processing libraries

COPY package.json .
RUN npm install

COPY . .
RUN npm run build

CMD [“npm”, “run”, “start:prod”]

Note: The Dockerfile does NOT include image processing libraries (libpng-dev, libjpeg-dev, libtiff-dev, zlib1g-dev) which were commented out, suggesting we weren’t originally concerned about image handling.

ERROR DETAILS

Process Crash Signal:

PID 61 received SIGSEGV for address: 0x10
Segmentation fault (core dumped)

Full Stack Trace:

/app/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3248)[0x7fd7d8be4248]
/lib/x86_64-linux-gnu/libc.so.6(+0x3c050)[0x7fd7db4e6050]
node(_ZN15node_napi_env__8DeleteMeEv+0x26)[0xf4d3a6]
node(_ZN4node12CleanupQueue5DrainEv+0xce)[0xec42ee]
node(_ZN4node11Environment10RunCleanupEv+0xdd)[0xef8dad]
node(_ZN4node15FreeEnvironmentEPNS_11EnvironmentE+0x81)[0xe97b21]
node(_ZN4node6worker6Worker3RunEv+0x11d9)[0x10d2a79]
node[0x10d2b69]
/lib/x86_64-linux-gnu/libc.so.6(+0x891f5)[0x7fd7db5331f5]
/lib/x86_64-linux-gnu/libc.so.6(+0x1098dc)[0x7fd7db5b38dc]
Segmentation fault (core dumped)

Analysis:

  • The crash originates in NAPI environment cleanup (_ZN15node_napi_env__8DeleteMeEv)
  • Occurs during Worker Thread termination (node6worker6Worker3RunEv)
  • Triggered by libc memory operations, indicating a use-after-free or invalid pointer dereference
  • NOT occurring during conversion itself, but during resource cleanup

RELEVANT CODE IMPLEMENTATION

We’re using Node.js Worker Threads for concurrent PDF batch processing with the following approach:

class PDFServiceWorker {
private adminPassword: string = process.env.PDF_ADMIN_PASSWORD!;

public generateSimpleBatchPDFsWithWatermarks = async (batchRequest: any) => {
// Process multiple watermark variations sequentially
for (let i = 0; i < watermarks.length; i++) {
let workbook: Workbook | null = null;

  try {
    // Load Excel file with images into Aspose workbook
    workbook = new Workbook(tmpExcelPath); // ⚠️ Issue likely here with image handling
    
    // Configure PDF options with watermark
    const saveOptions = this.configureAsposePdfOptions(currentWatermark);
    
    // Convert Excel to PDF (with embedded images)
    workbook.save(tmpBasePdfPath, saveOptions);
    
    // Apply security/encryption
    if (password) {
      await this.addEncryption(encryptionOptions, tmpBasePdfPath);
    }
    
    // Read and process PDF
    finalPdfBuffer = await fsPromises.readFile(tmpOutputPath);
    const base64Pdf = finalPdfBuffer.toString("base64");
    
  } finally {
    // Cleanup workbook - this is where crash occurs on Linux
    if (workbook) {
      if (typeof workbook.dispose === "function") {
        workbook.dispose(); // ⚠️ Potential native crash point
      }
      workbook = null;
    }
    
    // Force garbage collection
    if (global.gc) {
      global.gc();
    }
  }
}

};
}

Memory Management Attempts:

  • :white_check_mark: Explicit workbook disposal with workbook.dispose()
  • :white_check_mark: Manual garbage collection with global.gc()
  • :white_check_mark: Buffer clearing: finalPdfBuffer = Buffer.alloc(0)
  • :white_check_mark: Worker thread resource cleanup
  • :white_check_mark: Temp file cleanup in finally blocks

KEY PACKAGE VERSIONS

{
“aspose.cells.node”: “^25.12.0”,
“aspose-pdf-js”: “^25.10.0”,
“pdf-lib”: “^1.17.1”,
@pdf-lib/fontkit”: “^1.1.1”,
“coherentpdf”: “^2.5.5”,
“segfault-handler”: “^1.3.0”,
“node”: “22”
}


DETAILED PROBLEM DESCRIPTION

What Works:

  • :white_check_mark: Converting simple Excel files (text only) to PDF on Linux
  • :white_check_mark: Adding watermarks via Aspose RenderingWatermark
  • :white_check_mark: Applying PDF encryption with PdfSecurityOptions
  • :white_check_mark: Merging PDFs using pdf-lib
  • :white_check_mark: ALL operations on Windows with identical code and data

What Fails:

  • :x: Converting Excel files with embedded images on Linux
  • :x: Specifically crashes during workbook cleanup phase
  • :x: Happens after successful PDF generation (PDF is created fine)
  • :x: Crash is non-deterministic but highly reproducible with image-heavy files

Observations:

  1. The PDF is successfully generated and written to disk BEFORE the crash
  2. The crash happens during the finally block cleanup, specifically at workbook.dispose()
  3. Windows handles the same Excel files with images without any issues
  4. The native Aspose.Cells C++ binding appears to have different behavior on Linux vs Windows
  5. Memory profiling shows no obvious leaks before the crash - crash is in native code

CRITICAL QUESTIONS FOR ASPOSE SUPPORT

  1. Is there a known incompatibility between Aspose.Cells.Node v25.12.0 and:

    • Node.js 22 on Linux/Debian?
    • Image processing in Excel files on Linux platforms?
  2. Native Dependency Issue: Does Aspose.Cells.Node require specific system libraries for image handling on Linux that aren’t included by default in the node:22 Docker image?

  3. OEM License Specifics: Could there be platform-specific behavior differences in OEM license validation or initialization on Linux vs Windows?

  4. Memory Management: Are there platform-specific memory management patterns we should follow when disposing Workbooks containing images on Linux?

  5. Recommended Solution: Should we:

    • Downgrade Node.js version?
    • Add missing system dependencies to Docker?
    • Use a different conversion approach for image-heavy files on Linux?
    • Update the OEM license on the Linux server?

WORKAROUND ATTEMPTS

We’ve tried:

  • :x: Disabling global.gc() calls
  • :x: Increasing Node.js heap size (–max-old-space-size=4096)
  • :x: Removing workbook.dispose() call (worker thread crashes instead)
  • :x: Converting Excel to PDF without watermarks/encryption
  • :x: Processing one file at a time vs batch processing

None of these resolved the Linux-specific issue.


Thank you for your assistance. This is blocking our production deployment.

@ypurohit005

The material you posted does not contain any published guidance that addresses the points you are asking about, so I can only report what is not documented:

  • The Aspose.Cells for Node.js via C++ documentation does not list any Linux system libraries that must be present for image handling — there is no mention of libpng, libjpeg, libtiff, zlib or similar dependencies in the supplied sources [0].
  • There is no documented incompatibility between Aspose.Cells for Node.js v25.12.0 and Node 22 on Debian/Ubuntu Linux [0].
  • The OEM‑license documentation does not describe any platform‑specific validation or runtime behavior that differs between Windows and Linux [0].
  • No special memory‑management pattern (e.g., alternative disposal sequence, explicit native‑resource release) is described for workbooks that contain images on Linux [0].

Because the official docs do not cover these scenarios, the following generic steps are usually helpful when a native‑extension crashes on Linux:

  1. Verify native image libraries – many native image‑processing components depend on libpng, libjpeg, libtiff, and zlib. Adding the corresponding -dev packages to the Docker image (e.g., apt‑get install -y libpng-dev libjpeg-dev libtiff-dev zlib1g-dev) often resolves segmentation faults that occur only when images are processed.
  2. Test with a supported Node LTS version – while the docs do not list an incompatibility, some native bindings have only been validated against Node 18/20. Running the same code under Node 20 (the current LTS) can help isolate a Node‑22‑specific issue.
  3. Upgrade to the latest Aspose.Cells for Node.js – if a newer patch release is available, it may contain fixes for Linux‑specific native cleanup.
  4. Collect a native crash dump – enable core‑dump generation inside the container and provide the dump to Aspose technical support; the stack trace you posted already shows the crash occurs during N‑API environment cleanup, which is a typical place where a use‑after‑free in the native library would surface.
  5. Isolate the disposal call – as a diagnostic, comment out workbook.dispose() and let the process exit normally (or run the worker without explicit disposal). If the process still crashes, the fault is likely inside the native destructor that runs automatically; if it does not, the explicit dispose() may be triggering the bug.

If after trying the above the problem persists, please attach the core dump and the exact version numbers of the native libraries (ldd output for libAsposeCellsNode.so or similar) so that the Aspose engineering team can investigate the native crash further.

@ypurohit005,

Thank you for providing the details.

Could you please compress the template Excel file (having embedded images/shapes) into a zip file and attach it here? We will check your issue soon. If the zipped file size exceeds the limit (10MB), please consider uploading it to a file-sharing service (e.g., Dropbox, Google Drive, etc.) and sharing the download link (ensuring no credentials are required).

Could you try to reproduce this using the details below? We cannot generate the PDF on our Linux server, while it works fine on our local Windows environment.

Aspose-Test-file.zip (627.4 KB)

@ypurohit005,

Thanks for the template Excel file.

We require a thorough evaluation of the issue you mentioned in the Linux environment to ensure accurate diagnosis and resolution. We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): CELLSNODEJSCPP-70

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

@ypurohit005
Thank you for providing the details. I can reproduce the error you described on Linux. Aspose.Cells for Node.js via C++ is not thread-safe, which can cause various concurrency errors in a Node.js Worker Threads environment. I will continue to research how to support Node.js Worker Threads. Additionally, I tested it with process concurrency on Linux & Windows, and it works fine. Hopefully, this solution can resolve the issue. Thank you.
node-process-concurrent.zip (1006 Bytes)

Could you provide the exact list of libraries and dependency packages installed on the Linux server so we can replicate the setup?

@ypurohit005
The aspose.cells.node.linux.x64 library primarily includes two shared libraries: libAspose.Cells.so and aspose.cells.nodejs.node. Their corresponding dependencies are:
[libfontconfig.so.1]
[libfreetype.so.6]
[libpthread.so.0]
[libdl.so.2]
[libstdc++.so.6]
[libm.so.6]
[libgcc_s.so.1]
[libc.so.6]
[ld-linux-x86-64.so.2]
[libuuid.so.1]

and
[libAspose.Cells.so]
[libstdc++.so.6]
[libgcc_s.so.1]
[libc.so.6]

No additional image processing libraries (libpng-dev, libjpeg-dev, libtiff-dev, zlib1g-dev) and other libraries are required.

If the PDF renders with incorrect fonts, please refer to How to Install Fonts in Linux|Documentation for instructions on how to install fonts on Linux.

FROM node:22

WORKDIR /app

RUN apt-get update && apt-get install -y
libfontconfig1
libfreetype6
libuuid1
libstdc++6
&& rm -rf /var/lib/apt/lists/*

COPY package.json .

RUN npm install

COPY . .

RUN npm run build

CMD [“npm”, “run”, “start:prod”]

This is our updated Dockerfile. Will these steps be sufficient for the image?
Could you please tell me which Linux packages you have installed?

@ypurohit005,

Thank you for sharing the Docker file contents with us. We will review them and get back to you with further details soon.

@ypurohit005
The following Dockerfile (node:20) can successfully run the conversion from .xlsx files containing images to PDF. No additional graphics libraries are required.

FROM node:20

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

CMD ["node", "index.js"]

When using the node:22 or node:24 Docker image, converting XLSX files containing images to PDF results in an error. However, running the same conversion with Aspose.Cells for C++ alone works without issue. This appears to be a compatibility issue with Aspose.Cells for Node.js via C++ in a Debian (bookworm) + Node.js 22 environment. I will investigate this issue thoroughly and notify you once it is resolved. Thank you.

@ypurohit005
We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): CELLSNODEJSCPP-72 - Segmentation fault when converting xlsx with image to pdf in Debian (bookworm) + Node.js 22

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.

@ypurohit005
Starting with the upcoming v26.1 release, Aspose.Cells for Node.js via C++ will be available in the node:22 docker. No additional graphics dependency libraries. Thanks.

The issues you have found earlier (filed as CELLSNODEJSCPP-72) have been fixed in this update. This message was posted using Bugs notification tool by Nick.Liu