Bug #6560
closedjava.lang.ClassCastException in SaxonJ-HE 12.5
0%
Description
I have a ClassCastException in SaxonJ-HE 12.5 and have attached a stylesheet which demonstrates the problem.
The stylesheet is:
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" />
<xsl:template name="xsl:initial-template">
<root>
<xsl:variable name="var01">abcdef</xsl:variable>
<xsl:analyze-string select="$var01/text()" regex="def">
<xsl:matching-substring>
<yes value="{.}" />
</xsl:matching-substring>
</xsl:analyze-string>
</root>
</xsl:template>
</xsl:stylesheet>
With 'miscellaneous' optimization disabled (-opt:-m) I get the following output:
<?xml version="1.0" encoding="UTF-8"?><root><yes value="def"/></root>
With 'miscellaneous' optimization enabled (-opt:m) I get the following crash output.
The trace below was produced with -t, -explain and -opt:m options (the explain output isn't included).
NOTE : if I remove the '/text()'
from the xsl:analyze-string select
attribute the crash no longer happens.
SaxonJ-HE 12.5 from Saxonica
Java version 11.0.23
OPT : At line 8 of file:/L:/Tests/Saxon/SaxonCrash/ClassCastExceptionCrash.xslt
OPT : Replaced variable var01 by its value
OPT : Expression after rewrite: abcdef
Stylesheet compilation time: 477.3962ms
Processing (no source document) initial template = xsl:initial-template
java.lang.ClassCastException: class net.sf.saxon.value.StringValue cannot be cast to class net.sf.saxon.om.NodeInfo (net.sf.saxon.value.StringValue and net.sf.saxon.om.NodeInfo are in unnamed module of loader 'app')
at net.sf.saxon.expr.SimpleStepExpression$SimpleStepExprElaborator.lambda$elaborateForPull$1(SimpleStepExpression.java:185)
at net.sf.saxon.expr.Atomizer$AtomizerElaborator.lambda$elaborateForPull$0(Atomizer.java:678)
at net.sf.saxon.expr.AtomicSequenceConverter$AtomicSequenceConverterElaborator.lambda$elaborateForPull$0(AtomicSequenceConverter.java:536)
at net.sf.saxon.expr.CardinalityChecker$CardinalityCheckerElaborator.lambda$elaborateForPull$0(CardinalityChecker.java:506)
at net.sf.saxon.expr.elab.PullElaborator.lambda$elaborateForItem$1(PullElaborator.java:54)
at net.sf.saxon.expr.elab.PullElaborator.lambda$elaborateForUnicodeString$3(PullElaborator.java:76)
at net.sf.saxon.expr.instruct.AnalyzeString$AnalyzeStringElaborator.lambda$elaborateForPush$2(AnalyzeString.java:473)
at net.sf.saxon.expr.LetExpression$LetExprElaborator.lambda$elaborateForPush$6(LetExpression.java:942)
at net.sf.saxon.expr.instruct.FixedElement$FixedElementElaborator.lambda$elaborateForPush$0(FixedElement.java:640)
at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:247)
at net.sf.saxon.trans.XsltController.callTemplate(XsltController.java:872)
at net.sf.saxon.s9api.Xslt30Transformer.callTemplate(Xslt30Transformer.java:503)
at net.sf.saxon.Transform.processFile(Transform.java:1391)
at net.sf.saxon.Transform.doTransform(Transform.java:894)
at net.sf.saxon.Transform.main(Transform.java:84)
Fatal error during transformation: java.lang.ClassCastException: class net.sf.saxon.value.StringValue cannot be cast to class net.sf.saxon.om.NodeInfo (net.sf.saxon.value.StringValue and net.sf.saxon.om.NodeInfo are in unnamed module of loader 'app')
Adrian
Files
Updated by Michael Kay about 1 month ago
Saxon13 running in IntelliJ with a license file gives me:
Type error at char 14 in expression in xsl:analyze-string/@select on line 10 column 62 of test.xsl:
XPTY0020 Axis step child::text() cannot be used here: the context item is not a node
which is clearly wrong. Perhaps a different manifestation of the same bug.
Given a variable like <xsl:variable name="S">abcdef</xsl:variable>
Saxon examines all references to the variable, and if they are all in an atomizing context, it bypasses the construction of a document node, and treats the variable as a string. It looks like that optimization is happening here when it shouldn't.
Updated by Michael Kay about 1 month ago
Yes, that's it. Given an atomized binary expression of the form data($A § $B)
, regardless of the operator §, Saxon is assuming both operands $A and $B are atomized, which is clearly not the case for an operator like /
. It's also wrong for operators like "is", "or", and "union".
The code in question is BinaryExpression.setFlattened()
.
Rather surprising that the bug should take quite so long to be discovered -- though nothing should surprise me any more. I guess it's probably quite unusual to declare a variable as <xsl:variable name="v">abcdef</xsl:variable>
and then use it as a node rather than as a string.
I'm sure you don't need telling that there are more efficient ways of writing this code...
Updated by Michael Kay about 1 month ago
- Category set to XSLT conformance
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 12, trunk added
- Fix Committed on Branch 12, trunk added
- Platforms .NET, Java added
Fixed by changing the setFlattened() method to take account of the operand usages.
Please register to edit this issue