Open rrthomas opened 8 months ago
To put the problem another way, I get the same voluminous output if I console.log(error.message)
as if I console.log(error)
.
Hey Reuben,
Oof, that sounds annoying. How would you repro this? is it something like this?
var fontoxpath = require("fontoxpath")
try {
fontoxpath.evaluateXPathToString('(1 to 100000)!(. to 100000) => sum()')
} catch (e) {
console.log('ERROR', e);
}
or are custom functions involved?
In my case it used a custom function, but I think a function that always recurses would do it. I'll look when I have a moment!
The example you give results in Node.js heap exhaustion, not XQuery stack exhaustion. That causes Node.js itself to crash; not a lot you can do here!
Here's an example that gives a short (if still unhelpful) backtrace, with a user-defined function:
import fontoxpath from 'fontoxpath'
try {
fontoxpath.evaluateXPathToString(`
declare function local:foo() {
local:foo()
};
local:foo()
`, undefined, undefined, undefined, {language: fontoxpath.evaluateXPath.XQUERY_3_1_LANGUAGE})
} catch (e) {
console.log('ERROR', e);
}
I suspect that the long node backtrace requires a custom function implemented in JavaScript.
When I cause fontoxpath to exhaust the Node.js stack (not fontoxpath's fault!), the error returned to my code contains the Node backtrace in the
.message
element. I wish it did not, as there's no easy way for me to avoid printing it while still printing the actual error (which would contain a long XQuery backtrace: not great, but still, at least that's the fault of my code!).I am running with
debug: false
.