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:
Works perfectly on Windows (local development)
Crashes on Linux Debian (production server)
Works fine with Excel files without images
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:
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:
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:
Explicit workbook disposal with workbook.dispose()
Manual garbage collection with global.gc()
Buffer clearing: finalPdfBuffer = Buffer.alloc(0)
Worker thread resource cleanup
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:
Converting simple Excel files (text only) to PDF on Linux
Adding watermarks via Aspose RenderingWatermark
Applying PDF encryption with PdfSecurityOptions
Merging PDFs using pdf-lib
ALL operations on Windows with identical code and data
What Fails:
Converting Excel files with embedded images on Linux
Specifically crashes during workbook cleanup phase
Happens after successful PDF generation (PDF is created fine)
Crash is non-deterministic but highly reproducible with image-heavy files
Observations:
- The PDF is successfully generated and written to disk BEFORE the crash
- The crash happens during the finally block cleanup, specifically at workbook.dispose()
- Windows handles the same Excel files with images without any issues
- The native Aspose.Cells C++ binding appears to have different behavior on Linux vs Windows
- Memory profiling shows no obvious leaks before the crash - crash is in native code
CRITICAL QUESTIONS FOR ASPOSE SUPPORT
-
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?
-
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?
-
OEM License Specifics: Could there be platform-specific behavior differences in OEM license validation or initialization on Linux vs Windows?
-
Memory Management: Are there platform-specific memory management patterns we should follow when disposing Workbooks containing images on Linux?
-
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:
Disabling global.gc() calls
Increasing Node.js heap size (–max-old-space-size=4096)
Removing workbook.dispose() call (worker thread crashes instead)
Converting Excel to PDF without watermarks/encryption
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.