Bug #2021: Various odd issues --- crashing when maps called with empty arguments - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2021

closed

Various odd issues --- crashing when maps called with empty arguments

Added by David Rudel about 10 years ago. Updated about 10 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

XSLT conformance

Sprint/Milestone:

Start date:

2014-03-10

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

Fix Committed on Branch:

Fixed in Maintenance Release:

Platforms:

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

Public_Map_Error.xsl (952 Bytes) Public_Map_Error.xsl

David Rudel, 2014-03-10 18:35

Actions

Copy link

Updated by Michael Kay about 10 years ago

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.

Actions

Copy link

Updated by Michael Kay about 10 years ago

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.

Actions

Copy link