Error: RangeError: Maximum call stack size exceeded

[adbruijns]

Description

Error: RangeError: Maximum call stack size exceeded

xmlData is a large xhtml file - about 46MB

Input

After updating from 5.5.10 to 5.5.12 the parser gives the above error!
The 5.5.10 version, or lower, works fine.

Code

const parser = new XMLParser(options));
try {
const jObj = parser.parse(xmlData)
return jObj;
} catch (err) {
throw new Error(err);
}

Output

expected data

Would you like to work on this issue?

• Yes
• No

Bookmark this repository for further updates. Visit SoloThought to know about recent features.

[github-actions]

We're glad you find this project helpful. We'll try to address this issue ASAP. You can join Discord channel(https://discord.gg/X4Qp9u6Vz) for anonucements and pre release discussions. Don't forget to star this repo.

[amitguptagwl]

I tested it for 101 mb file on my local and it was working fine. Can you please share the stacktrace?

[adbruijns]

The xhtml file can be downloaded from here.
The downloaded xbri package can be unzipped and the reports folder contains the xhtml file that gives the problem.

[kroehrs]

Hitting the same issue

[amitguptagwl]

As I requested, can you please share the stacktrace?

[adbruijns]

const {XMLParser} = require("fast-xml-parser");
const fs = require('fs');

const xmlData = fs.readFileSync(".../....xhtml"); // the contents of the file mentioned above
const parser = new XMLParser();
try {
const jObj = parser.parse(xmlData)
} catch (err) {
throw new Error(err);
}

Error: RangeError: Maximum call stack size exceeded
at Object. (C:\Users\ad\WebstormProjects\test\rangeError.js:10:11)
at Module._compile (node:internal/modules/cjs/loader:1706:14)
at Object..js (node:internal/modules/cjs/loader:1839:10)
at Module.load (node:internal/modules/cjs/loader:1441:32)
at Function._load (node:internal/modules/cjs/loader:1263:12)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at node:internal/main/run_main_module:36:49

Problem also exists in the 5.6.0 version.

[adbruijns]

Extra information about the file. The function below returns "true"

function validateXML(xmlData) {
try {
return XMLValidator.validate(xmlData.toString());
} catch (err) {
throw new Error(err);
}
}

[Kirylka]

Same error here. Bisected on a 12 MB XML input:

• 5.5.6 → ok (~877ms)
• 5.5.7 → ok
• 5.5.8 → ok
• 5.5.9 → ok
• 5.5.10 → ok (~774ms)
• 5.5.11 → fails in ~19ms
• 5.5.12 → fails in ~18ms
• 5.6.0 (latest) → fails in ~43ms

So the regression landed in the 5.5.10 → 5.5.11 delta and every release since (including current latest 5.6.0) is still broken.

Fails almost instantly, not mid-traversal:

RangeError: Maximum call stack size exceeded
    at fast-xml-parser/lib/fxp.cjs:1:32071
    at st (fast-xml-parser/lib/fxp.cjs:1:32217)
    at U.J [as parseXml] (fast-xml-parser/lib/fxp.cjs:1:27415)
    at xt.parse (fast-xml-parser/lib/fxp.cjs:1:37228)

The file is an Adobe After Effects .aepx. ~128k lines, ~101k tags (42k pairs + 59k self-closing), max nesting depth is only 15, 24 entity refs (all 
 / 
), no DOCTYPE, no <!ENTITY>. So depth isn't the trigger — looks more like something around the volume of self-closing tags.

Parser options:

{
  ignoreAttributes: false,
  attributeNamePrefix: "@",
  processEntities: { maxTotalExpansions: Infinity },
}

Crashes with or without the processEntities override. Node 22.15, macOS arm64.

[Kirylka]

Opened a PR with a fix: #820

Root cause is in tagExpWithClosingIndex (new in 5.5.11): it builds a chars array of char codes and returns via String.fromCharCode(...chars). For a large enough tag expression the spread exceeds V8's per-call argument limit and surfaces as the RangeError (hence the shallow 4-frame trace — not recursion).

Swapping the spread for a xmlData.substring(i, index).replace(/\t/g, ' ') preserves the exact semantics, passes all 310 existing specs plus a regression test, and produces byte-identical output to 5.5.10 on the 12MB file I was testing against.

[amitguptagwl]

This issue was fixed in v5.7.2. Let me know if any work is remaining.