Saxon

The test appears to work when run standalone; it fails only when the whole -s:package test set is run.

Running -t:package-(001|101) is enough to trigger the failure.

Confirmed that when we run -t:package-101, in UserFunctionCall.allocateArgumentEvalluators(), the call to getFunction() returns a function; but when we run with -t:package-(001|101), the same call returns null.

The function call in question is

<xsl:copy-of select="csv:parse($input)" />

on line 18 of package101.xsl

It seems that on reloading the SEF file, we fix up component references using the code:

private void resolveFixups() throws XPathException {
        StylesheetPackage pack = packStack.peek();
        for (ComponentInvocation call : fixups.peek()) {
            if (processComponentReference(pack, call)) {
                break; // It will have a binding slot
            }
        }
        pack.allocateBinderySlots();
    } 

In PackageLoaderHE#3544. This code is unchanged from Saxon 11 and Saxon 10. The value of fixups,peek() is a list of fixup actions to be processed, and it is not at all clear why we should stop processing the list of actions when one of them returns true.

When we run the test on its own, there are three actions to be processed. The last is to process an attribute-set reference to xsl:original, and this is the only one that returns true, so all three actions are processed. When we run the test in conjunction with package-001, the three actions to be processed are in a different order, with the attribute-set reference coming first; as a result, the subsequent actions are not processed, leading to the null pointer exception when we find that the user function call has not been fixed up.

The order in which components are processed, and therefore the order in which the fixups are performed, is unpredictable. I don't know why running a second test disturbs the order, but there is essentially no reason why it shouldn't. I think we've hit a bug in the code that has always been there and which only manifests itself with low probability.

processComponentReference() returns true ONLY for a call to xsl:original, and I simply can't see any logic for breaking the loop at this point and not fixing up other references.