Project

Profile

Help

Bug #4985

NullPointerException in Saxon-EE

Added by Gerben Abbink about 1 month ago. Updated about 1 month ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2021-05-07
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:

Description

I get an NullPointerException when i run the attached stylesheet in Saxon-EE, latest version.

Saxon-HE gives no NullPointerException.

The stylesheet is part of the XSLT 3.0 Test Suite:

..\xslt30-test-b42c1b89b44f\report\viewer\process.xsl

process.xsl (6.01 KB) process.xsl Gerben Abbink, 2021-05-07 16:41

History

#1 Updated by Michael Kay about 1 month ago

The stylesheet should report errors (assuming you're not running with target:JS), because it calls constructs that aren't available in Saxon/J, such as ixsl:schedule-action and xsl:query-params(). But of course it shouldn't fail with an NPE.

I think the reason it's crashing is that it's a bit inconsistent as to whether the children of ixsl:schedule-action are treated as instructions or not.

The relevant rule for the xsl:schedule-action element is:

[ERR XTDE1450] When a processor performs fallback for an extension instruction that is not recognized, if the instruction element has one or more xsl:fallback children, then the content of each of the xsl:fallback children must be evaluated; it is a dynamic error if it has no xsl:fallback children.

But in fact we won't get that far: the instruction will never be evaluated because the stylesheet contains errors (the call on ``xsl:query-params()`).

If we had no knowledge at all of the xsl:schedule-action instruction, then I think it's an open question whether we should validate the contained xsl:call-template: I don't think the spec answers this question. But the crash occurs because we are doing half the work of validating it, and not the other half. Given that we do have knowledge of the instruction, I think it makes sense to validate the contained instruction fully.

#2 Updated by Michael Kay about 1 month ago

  • Category set to XSLT conformance
  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

For reasons which I don't understand, the error in the text-value-template at line 41 (specifically, the call on ixsl:query-params) is causing the prepare-attributes phase of processing on template main to be abandoned, meaning that when the validate phase is subsequently run, the call-template instruction is processed in validate mode without first having been processed in prepare-attributes mode.

#3 Updated by Michael Kay about 1 month ago

The solution is for TextValueTemplateNode.parse() to catch any error thrown by the call on AttributeValueTemplate.make(), and report it via StyleElement.compileError(), rather than letting it bubble upwards causing the processing of the containing component to be abandoned.

#4 Updated by Michael Kay about 1 month ago

  • Status changed from In Progress to Resolved
  • Applies to branch trunk added
  • Fix Committed on Branch 10, trunk added

Please register to edit this issue

Also available in: Atom PDF