Bug #2021
closed
Various odd issues --- crashing when maps called with empty arguments
Category:
XSLT conformance
Fixed in Maintenance Release:
Description
The attached XSLT crashes with no error output when run as-is. If the commented line is toggled, it crashes with an "javaNullPointerException" error, which is not very helpful.
Expected behavior is to throw an error indicating that a function item cannot be called with an empty sequence as argument.
NOTE: there are some very strange nuances going beyond the above, and I suspect there are multiple issues here:
-
In particular, note the declaration statement for variable $c. This is a variable that is not used anywhere, so it should not affect anything. However, somehow the inclusion of this variable statement prevents the interpreter from recognizing the error. If this variable statement is commented out, a useful error is displayed when execution is attempted.
-
The strange behavior described in point 1 is itself dependent on other nuances that one would not expect to make any difference. In particular, if the "@a" is removed from the declaration of variable $a, this behavior no longer occurs and program crashes no matter what (regardless of whether the $c variable statement exists). Similarly, a version that does not have the $b declaration, and instead uses $a in the for-each will also not show this odd dependence on the existence of this variable.
-
If the variable declaration for $c references $b instead of $a, it no longer provides the shielding effect mentioned in number 1 and an error is reported in all cases.
-
Not shown by this template, but in other cases no error or crash occurs at all and the output provided is the set of keys to the map, even if the procedure used to create the map should have yielded an error.
Files
- Category set to XSLT conformance
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Priority changed from Low to Normal
(Notes to self): First problem is that $map(()) is crashing with a NullPointerException rather than a type error. This happens with both implementation classes ImmutableMap and SingletonMap. However, passing a sequence of two numbers is correctly rejected, and when an element is passed as the argument, it is correctly atomized, so some type checking is occurring. In the first case the failure occurs in CardinalityCheckingIterator, and the cardinality it is checking for is EXACTLY_ONE. This is called from TypeHierarchy.applyFunctionConversionRules(), invoked from DynamicFunctionCallDefinition.call().
TypeHierarchy.applyFunctionConversionRules() contains the logic
if (iterator instanceof EmptyIterator) {
return EmptySequence.getInstance();
}
which is incorrect; it bypasses checks on the cardinality. Removing this code fixes the problem (the type error is now correctly reported). Need to regression-test this change. It's likely the test was put in there because in this situation the item type will be xs:error, which might cause probems with the item type checking.
- Status changed from In Progress to Resolved
The patch appears to cause no regression.
The various permutations of the problems are not unexpected, and I don't propose to investigate them in detail. Small differences in a query can produce radical differences in the output of optimization, and while this is not observable if Saxon is behaving correctly, it can very easily lead to differences where a bug is exposed on one path and not on another. Of course if the optimizer were perfect then an unused variable would make no difference to the outcome; but optimizers work by a sequence of steps recognizing patterns that can be rewritten, and in general the order of these steps affects the outcome. I suspect that the presence of the unused variable $c initially prevents $a being inlined within the definition of $b, and this then affects the subsequent course of events: the -explain output shows how different the sequence of rewrites is in the two cases.
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Found in version changed from 9.5.1.3 to 9.5
- Fixed in version set to 9.5.1.5
Bug fix applied in Saxon maintenance release 9.5.1.5
Please register to edit this issue
Also available in: Atom
PDF
.