XSLTProcessor fails on a large XML document, hitting maxdepth limit

[Dustin]

This is reproducible with Google Chrome 13.0.782.218 and Safari 5.1 on OS X 10.6, as well as Google Chrome 13.0.782.215 on Linux with kernel 3.0.0.  Safari 5.0.6 is not affected.

When using the JavaScript transformToDocument() method to transform a large XML file (> 2.1MB), it returns an undefined rather than a Document.  When using the transformToFragment() method it returns null.

The XML Document has a maximum depth of seven (7) and contains 85790 lines.

The attached XML file will reproduce it.  It contains public astronomical data.

Thank you.

[Dustin]

Created attachment 105813 [details]
Public astronomical XML file.  Should be 2.9MB.

[Alexey Proskuryakov]

Could you please attach your XSLT file, too?

[Dustin]

Created attachment 105989 [details]
XSL File for the attached XML.

This is the XSL file.

[Dustin]

// Small code sample of how it's being used.
//

var renderProcessor = new XSLTProcessor();
var renderXSLDOM = getXSLFromService(...);
var myDOM = getXMLFromService(...);

if (renderProcessor.reset)
{
  renderProcessor.reset();
}

try
{
  renderProcessor.importStylesheet(renderXSLDOM);

  // Set parameters...
  rederProcessor.setParameter(...);

  displayFragment = renderProcessor.transformToDocument(myDOM);
  
  // displayFragment is undefined.
}
catch (e1)
{
  alert("Found error! >> " + e1);
}

[Alexey Proskuryakov]

Created attachment 105993 [details]
full test case (doesn't reproduce)

Thank you!

I tried to make an in-browser test case, but I cannot reproduce the problem in Safari 5.1 on Mac OS X Lion. I get an alert saying "[object Document]", so the result is not undefined.

Could you please take a look to find a difference with your case?

[Dustin]

Created attachment 105994 [details]
CORRECT XSL File!

Sorry!  This is the correct XSL file.

[Alexey Proskuryakov]

Just to confirm, is this transformation expected to work correctly without any parameters set?

I can reproduce a problem with the new xsl file (filter.xsl). Firefox quickly produces a document, while WebKit takes much longer, and shows "undefined".

I can also reproduce this error with command line libxslt utility on Mac OS X:

$ xsltproc filter.xsl data.xml
runtime error: file /Users/ap/.Trash/large-xsl/filter.xsl line 120 element param
xsltApplyXSLTTemplate: A potential infinite template recursion was detected.
You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000).

This doesn't occur if I set maxdepth to 6000. Not sure if we should increase it.

[Dustin]

First, thank you for the quick replies.  This is great.

renderProcessor.setParameter(null, "pageStart", 1);
renderProcessor.setParameter(null, "pageEnd", 100);

These are the only two parameters set for this.

Thanks for the xsltproc command.  That will help debug.

Dustin

[Dustin]

Hi Alexey,

I'm not sure how to work around this.  The issue could be with the XSL file itself, to be fair, but I was just wondering where this ticket was left.  I'm still debugging this too.

Many thanks,
Dustin

[Alexey Proskuryakov]

It's fairly unlikely that any further action on this bug will happen very soon.

I suggest asking on an XSL users mailing list for workaround ideas (unfortunately, I don't have specific pointers). It's indeed possible that a small modification of the stylesheet would avoid hitting this problem.

[Dustin]

I will.  Thanks, Alexey.

Dustin