Project

Profile

Help

Bug #3645

closed

java.lang.AssertionError: **** Component reference function df:class#2 is already bound

Added by Radu Coravu about 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2018-01-25
Due date:
% Done:

100%

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

Description

Summary: This error occurs when a stylesheet module is imported multiple times by different routes, and the module contains a template rule with a match pattern containing a predicate that makes a function call to a user-defined function.

Trying to validate or to transform with a certain XSLT generates this exception with Saxon 9.8:

java.lang.AssertionError: **** Component reference function df:class#2 is already bound
	at net.sf.saxon.expr.instruct.Actor.processComponentReference(Actor.java:146)
	at net.sf.saxon.expr.instruct.Actor.allocateBindingSlotsRecursive(Actor.java:109)
	at net.sf.saxon.expr.instruct.Actor.allocateBindingSlotsRecursive(Actor.java:112)
	at net.sf.saxon.trans.SimpleMode$2.processRule(SimpleMode.java:952)
	at net.sf.saxon.trans.SimpleMode.processRuleChain(SimpleMode.java:1148)
	at net.sf.saxon.trans.SimpleMode.processRules(SimpleMode.java:1074)
	at net.sf.saxon.trans.SimpleMode.processRules(SimpleMode.java:1062)
	at net.sf.saxon.trans.SimpleMode.forceAllocateAllBindingSlots(SimpleMode.java:950)
	at net.sf.saxon.trans.SimpleMode.allocateAllBindingSlots(SimpleMode.java:941)
	at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1377)
	at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:328)
	at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:258)
	at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:106)
	at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:739)
	at net.sf.saxon.jaxp.SaxonTransformerFactory.newTemplates(SaxonTransformerFactory.java:175)
	at net.sf.saxon.jaxp.SaxonTransformerFactory.newTransformer(SaxonTransformerFactory.java:131)

I'm working on some samples, I will attach them a little bit later, basically the same XSLT stylesheet seems to be imported on two branches, resulting in this problem being reported.


Files

saxonicaBug.zip (17.4 KB) saxonicaBug.zip Radu Coravu, 2018-01-25 11:08
Actions #1

Updated by Radu Coravu about 6 years ago

Attached some sample XSLTs, basically when compiling the "main.xsl" that particular error is thrown.

Actions #2

Updated by Michael Kay about 6 years ago

Thanks. I can see what's happening here, but will have to think about how best to fix it.

When a stylesheet module is imported by two different routes at different import precedences, components such as named templates and functions effectively exist only once at the higher precedence. But template rules have multiple instances at different precedences: the lower-precedence instances are evaluated when a higher-precedence rule calls xsl:next-match or xsl:apply-imports. Because we've seen pathological cases where a template rule in a shared library module exists at 50 different import precedences. we make sure that the "code" (expression tree) for the template rule exists only once, but there are multiple Rule objects, one for each precedence, referencing the same TemplateRule object.

It looks as if the code for allocating binding slot numbers for component references is processing such a rule twice. This generally indicates a problem (it often means that a subtree that should have been copied is actually reachable by more than one route in the expression tree) so we put in an "assertion" in 9.8 to check that it doesn't happen, and this assertion has been triggered.

Actions #3

Updated by Michael Kay about 6 years ago

In fact there is logic to prevent this happening for component references in the body of a template rule: see SimpleMode.forceAllocateAllBindingSlots(). But the problem here is a component reference (specifically, a function call) appearing in the match pattern, where the same logic does not apply.

Actions #4

Updated by Michael Kay about 6 years ago

  • Category set to Internals
  • Status changed from New to Resolved
  • Assignee set to Michael Kay
  • Priority changed from High to Normal
  • Applies to branch 9.8, trunk added
  • Fix Committed on Branch 9.8, trunk added

Fixed by changing SimpleMode.forceAllocateAllBindingSlots to do the same for match patterns as it does for template rule bodies: keep track of patterns that have been processed and only process each pattern once.

Actions #5

Updated by Michael Kay about 6 years ago

  • Description updated (diff)
Actions #6

Updated by Radu Coravu about 6 years ago

Thanks Michael.

Actions #7

Updated by O'Neil Delpratt about 6 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.8.0.8 added

Bug fix applied in the Saxon 9.8.0.8 maintenance release.

Please register to edit this issue

Also available in: Atom PDF