[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Maximum recursion depth exceeded

Subject: Re: Maximum recursion depth exceeded
From: George Cristian Bina <george@xxxxxxxxxxxxx>
Date: Tue, 07 Jul 2009 11:36:43 +0300
Re:  Maximum recursion depth exceeded
Hi Jesper,

oXygen sets a trace listener on Saxon to be able to offer the "Stop Transformation" action that allows users to stop a transformation at any time. That causes more method calls as Saxon will call the listener on all instructions and the transformation requires more stack memory. For example I was able to run your transformation setting the stack for oXygen to 10MB.
In the current development code of oXygen we found another way to implement the "Stop Transformation" action, without setting a trace listener on Saxon and your stylesheet works without problems with the default stack memory.

Best Regards,
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger

Jesper Tverskov wrote:
Hi list

When preparing for my article, "Google's Writely and XSLT for web
pages", http://www.xmlplease.com/writely2xhtml, basically a
writely2xhtml transformation, using David Carlisle's htmlparse.xsl,
http://dpcarlisle.blogspot.com/2007/04/htmlparse-updated.html, to do
an important part of the job, I have experienced an interesting

The transformation goes well with Saxon at the command line and from
inside .net but fails from inside XML Editors like Oxygen and Stylus
Studio. It also fails from inside XMLSpy using AltovaXML.

The XML editors return an error message saying something like "Maximum
recursion depth exceeded" or "too many nested function calls". I have
filed this "bug" at the three XML Editors.

_ _ _ _ _

Tony Lavinio in the Stylus Studio Forum has given this great explanation:

"The difference is most likely coming from the optimizer.

When you run Saxon within Stylus Studio (or Oxygen), in order to provide
debugging support we disable the optimizer. The Saxon optimizer will
reorder code, eliminate variables, and push expressions up or down the
stack. It also controls tail-call recursion.

If we didn't disable the optimizer while within the IDE, there is no
way you could follow the code, since the executable path doesn't really
look like the source document anymore.

When run outside an IDE, optimization is enabled.

You could try using smaller input sets while within the IDE environment,
but this is part of the cost of using a high-level language with a
clever optimizer."

_ _ _ _ _

It is interesting to note that my test documents failing in the XML
Editors still work when made 10 times longer at command line and from
inside .net.

Now my question to the XSL list:

Is the above problem the one and only exception or do we have other
situations where a transformation in an XML Editor is likely to fail
even when the same transformation works well at the command line or
from inside .net or java?

Jesper Tverskov


Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.