Bug #2663
closed
java.lang.AssertionError: Internal error: no value for variable $vv:gg2097915420 at line 11 of
Category:
XSLT conformance
Fix Committed on Branch:
9.7
Fixed in Maintenance Release:
Description
The following stylesheet generates java.lang.AssertionError: Internal error:
The error seems to be trigger by the doc or document function call using a literal URL and only on Saxon Enterprise Edition.
Complete test case attached.
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes" />
<xsl:template match="/">
<Catalog>
<Book>
<xsl:for-each select="books/book/title">
<Title><xsl:value-of select="."/></Title>
</xsl:for-each>
</Book>
<xsl:copy-of select="doc('file:///c:/temp/examples/simpleMappings/books0.xml')"/>
</Catalog>
</xsl:template>
</xsl:stylesheet>
java.lang.AssertionError: Internal error: no value for variable $vv:gg967248498 at line 11 of
Files
- Category set to XSLT conformance
- Status changed from New to AwaitingInfo
- Assignee set to Michael Kay
I can't reproduce the problem.
Could you be more precise about exactly how you are running the stylesheet? If from the command line, what's the command?
Which Java version?
Does it go away with bytecode disabled (--generateByteCode:off) ?
The error seems to be trigger by the doc or document function call using a literal URL and only on Saxon Enterprise Edition.
It's certainly related to that: the doc('xxx') is a constant expression that Saxon-EE will move into a global variable. But that doesn't get us much further. I would like to establish whether you have any settings that cause global variables to be evaluated eagerly (this typically happens when tracing is enabled). However, I've tried to run in that kind of configuration, and this still didn't trigger the error. Also, do you know whether the doc() function is actually executed, and whether it succeeds? With the -t option, Saxon should tell you when it is loading an external document; or you could monitor it with your own URIResolver.
I cannot replicate it from the command line, it happens when is wired in our code, may be is the the debugging mode.
It happens regardless byte code generation bit.
Running on Java 1.8.0_71 on Windows 10.
I will do more experiment, to narrow it down
I simplified the code to this, enabled the trace and turn bytecode off
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/">
<xsl:copy-of select="doc('file:///c:/temp/examples/simpleMappings/books0.xml')"/>
</xsl:template>
</xsl:stylesheet>
here is the output
<xsl:template match="/" line="4" column="27" module="sampleBooksToCatalog.xsl">
<xsl:copy-of line="5" column="85" module="sampleBooksToCatalog.xsl">
Exception in thread "main" java.lang.AssertionError: Internal error: no value for variable $vv:gg438314766 at line 5 of file:///c:/temp/examples/simpleMappings/sampleBooksToCatalog.xsl
at net.sf.saxon.expr.VariableReference.iterate(VariableReference.java:481)
at net.sf.saxon.expr.instruct.CopyOf.processLeavingTail(CopyOf.java:564)
at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:149)
at net.sf.saxon.expr.instruct.TraceExpression.processLeavingTail(TraceExpression.java:271)
at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:149)
at net.sf.saxon.expr.instruct.TraceExpression.processLeavingTail(TraceExpression.java:271)
at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:393)
at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:447)
at net.sf.saxon.Controller.transformDocument(Controller.java:2261)
at net.sf.saxon.Controller.transform(Controller.java:1863)
I strongly suspect this is essentially the same problem as bug #2606. But proving this is a bit tricky. I've tried without success to reproduce it on 9.7.0.2, and if I can't reproduce it then I can't be sure that it's fixed.
O'Neil is putting together a private snapshot build which he will make available so you can test whether the problem has gone away with our latest fixes.
Michael,
As discussed offline, the problem was triggered by calling Controller.transform without proper initialization. Using Transformer.transform works fine.
Thank you for your help!
Ivan
- Status changed from AwaitingInfo to Resolved
- Fix Committed on Branch 9.7 added
I have added improved state checking to various methods on Controller, so using an uninitialized Controller is now more likely to generate an IllegalStateException identifying the problem. Patch committed on the 9.7 branch.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.7.0.4 added
Bug fix applied in the Saxon 9.7.0.4 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF