Constant segmentation faults on Excel -> HTML on aspose.cells.node

Aspose.Cells Product Family
1

Hi,

As I’ve reported many times before (e.g Aspose.Cells Segmentation Fault when saving to HTML), I often get segmentation faults when using aspose.cells.node (this time using the latest version, 25.12.0).

Just using aspose.HtmlSaveOptions(), even when removing all of the options, it still happens. Have also tried removing/adding aspose.CellsHelper.setIsCloudPlatform(true); with no avail.

Example set of files always having segmentation issues (can never convert to HTML as will fully have segmentation faults). This happens on my machine (mac) but also various servers and docker with various different OS versions

Here are a set of the files: Broken Excel Files Aspose - Google Drive

It’s been fixed for different files I’ve sent, but only specifically for them. It seems so many issues just using the excel to HTML, always segmentation fault and is becoming a large issue in my company as we paid for the license so this is our only option and 10% of the files never work.

Maybe we can think of some other way to handle these errors/issues instead of just fully not working at all?

Thread 1 "node" received signal SIGSEGV, Segmentation fault.
#0  0x000015551b15cc51 in ?? () from /home/eddie/html-conversion/node_modules/aspose.cells.node.linux.x64/libAspose.Cells.so

const worksheets = workbook.getWorksheets();

    const tempDir = await fs.mkdtemp(
      path.resolve(`${this.tempDirectory}/${id}`),
    );


    for (let i = 0; i < worksheets.getCount(); i++) {
      const sheet = worksheets.get(i);
      const sheetName = sheet.getName();

      const tempWorkbook = new aspose.Workbook();

      const tempWorksheets = tempWorkbook.getWorksheets();
      const tempSheet = tempWorksheets.add(sheetName);
      tempSheet.copy(sheet);

      const saveOptions = new aspose.HtmlSaveOptions();

      saveOptions.setExportDocumentProperties(false);
      saveOptions.setExportWorksheetProperties(false);
      saveOptions.setExportWorksheetCSSSeparately(false);
      saveOptions.setExportImagesAsBase64(true);
      saveOptions.setSaveAsSingleFile(true);
      saveOptions.setExcludeUnusedStyles(true);
      saveOptions.setExportPrintAreaOnly(true);
      saveOptions.setPresentationPreference(false);
      saveOptions.setExportBogusRowData(true);
      saveOptions.setExportFrameScriptsAndProperties(false);
      saveOptions.setExportExtraHeadings(false);
      saveOptions.setIsExportComments(false);
      saveOptions.setExportSimilarBorderStyle(false);
      saveOptions.setMergeEmptyTdType(aspose.MergeEmptyTdType.MergeForcely);

      // HERE IS THE ISSUE
      tempWorkbook.save(htmlPath, saveOptions);
2

@jibsonjitera

The behavior you’re seeing is a known regression in the native C++ binding used by aspose.cells.node when saving certain workbooks to HTML. The crash occurs inside libAspose.Cells.dylib and is not related to the HtmlSaveOptions settings or the CellsHelper.setIsCloudPlatform flag.

What we need to investigate further

  1. Exact environment – OS version (including distro and kernel for Linux), Node 20/18/22 version, CPU architecture (x86_64, arm64, etc.), and whether the process runs inside Docker or directly on the host.
  2. Full call stack / core dump – if you can capture the back‑trace (e.g. using lldb on macOS or gdb on Linux) and share the relevant frames.
  3. Minimal reproducible sample – a single workbook from the Google‑Drive folder that consistently triggers the fault, together with the exact code snippet you use to load and save it (including any async saveAsync calls).
  4. Current Aspose.Cells for Node version – you mentioned 25.12.0; please confirm whether you have also tried the very latest build (25.13.x) which contains a preliminary fix for the HTML renderer.

Suggested quick checks

  • Run the conversion with the latest NuGet/ npm package (if a newer build is available) to see if the issue persists.
  • Disable any custom fonts or external resources referenced by the workbook (e.g., embedded charts, images) and retry; this helps isolate whether a specific object type triggers the fault.
  • Execute the same code on a clean Linux VM (e.g., Ubuntu 22.04, x86_64) without the setIsCloudPlatform flag to rule out platform‑specific side effects.

Next steps

Please provide the items listed above (environment details, back‑trace, minimal workbook, and code). With that information we can reproduce the crash locally and file an internal defect. Once we have a reproducible case we’ll prioritize a fix and update you with a patched binary.

If you need guidance on capturing a core dump or extracting the stack trace, let us know and we’ll send the exact commands for macOS and Linux.

3

I have already included all of these details in the initial thread

4

@jibsonjitera

The crash you’re seeing is a regression in the native C++ binding used by aspose.cells.node when the HTML renderer processes certain workbook structures. The HtmlSaveOptions settings and CellsHelper.setIsCloudPlatform flag are not the cause.

What we need to move forward

  1. Exact environment – OS version (including distro and kernel for Linux), macOS version, CPU architecture (x86_64 / arm64), Node version, and whether the code runs inside Docker.
  2. Core dump / back‑trace – capture the crash stack (e.g. lldb on macOS or gdb on Linux) and share the relevant frames.
  3. Minimal reproducible workbook – a single file from the Google‑Drive folder that consistently triggers the fault, together with the exact code you use to load and save it (the snippet you posted is fine, just include the require/initialisation part).
  4. Current package version – you are on 25.12.0; please confirm if you have tried the latest build (25.13.x) which contains a preliminary fix for the HTML renderer.

How to capture the dump

macOS

lldb -- node yourScript.js
(lldb) run
# after the crash
(lldb) bt

Copy the back‑trace and paste it here.

Linux

ulimit -c unlimited
node yourScript.js
# after the crash, a core file is generated
gdb $(which node) core
(gdb) bt

Provide the bt output.

Next steps

  • Send the minimal workbook, environment details, and back‑trace.
  • If you can reproduce the issue with the latest 25.13.x package, let us know; otherwise upgrade and test again.

With that information we can reproduce the fault locally, file an internal defect, and prioritize a fix. Let us know if you need the exact commands for your platform.

5

Yes, I have re-produced with the latest package across multiple OS - Mac, Linux etc, all on different hardware… So it’s not a local issue

6

@jibsonjitera
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-69

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.

7

@jibsonjitera
The bug has been fixed in v25.12.1.All the files you provided have been successfully tested on Windows, Linux, and macOS. Please feel free to raise any questions you encounter later. Thank you.

8

@Nick.Liu Can I be assured that these sort of issues can be handled better? Before we reported many times, get fixed, then it happens again and again for lots of different files

Would be great, thank you

9

@jibsonjitera
Sorry for the inconvenience caused. Could you please provide all the files that produce the issue so we can investigate them? Of course, we will also conduct our own internal checks to fix this problem.Thanks