Project

Profile

Help

Bug #5798

closed

Test case package-101 fails with -export:on

Added by Michael Kay about 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT export
Sprint/Milestone:
-
Start date:
2023-01-05
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, 11, trunk
Fix Committed on Branch:
10, 11, trunk
Fixed in Maintenance Release:
Platforms:
.NET, Java

Description

Intermittent NullPointerException when executing a two-package stylesheeet that has been reloaded from a SEF file.

In the XSLT3 test suite:

-s:package -t:package-101
Exported package to /Users/mike/w3c/qt3t/saxon/export/package/package-101.base.sef
java.lang.NullPointerException
	at net.sf.saxon.expr.UserFunctionCall.allocateArgumentEvaluators(UserFunctionCall.java:254)
	at net.sf.saxon.expr.UserFunctionCall.evaluateArguments(UserFunctionCall.java:628)
	at net.sf.saxon.expr.UserFunctionCall$UserFunctionCallElaborator.lambda$elaborateForPull$0(UserFunctionCall.java:762)
	at net.sf.saxon.expr.instruct.CopyOf$CopyOfElaborator.lambda$elaborateForPush$7(CopyOf.java:1045)
	at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:274)
Actions #1

Updated by Michael Kay about 1 year ago

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

Actions #2

Updated by Michael Kay about 1 year ago

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

Actions #3

Updated by Michael Kay about 1 year ago

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.

Actions #4

Updated by Michael Kay about 1 year ago

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.

Actions #5

Updated by Michael Kay about 1 year ago

  • Project changed from 20 to Saxon
  • Category set to XSLT export
  • Status changed from New to In Progress
  • Priority changed from Low to Normal
  • Applies to branch 10, 11, trunk added
  • Fix Committed on Branch trunk added
  • Platforms .NET, Java added

Removing the "break" solves the issue.

Leaving open because it needs to be fixed for earlier versions.

Actions #6

Updated by Michael Kay about 1 year ago

  • Description updated (diff)
Actions #7

Updated by Michael Kay about 1 year ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 10, 11 added

Fix now applied on 10.x and 11.x branches.

Actions #8

Updated by Community Admin about 1 year ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 12.0 added

Bug issue fix applied in the Saxon 12.0 Major Release. Leaving this bug marked as Resolved until fix applied

Actions #9

Updated by O'Neil Delpratt about 1 year ago

  • Fixed in Maintenance Release 11.5 added

Bug fix applied in the Saxon 11.5 maintenance release.

Actions #10

Updated by O'Neil Delpratt about 1 year ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 10.9 added

Bug fix applied in the Saxon 10.9 maintenance release.

Please register to edit this issue

Also available in: Atom PDF