Bug #3645: java.lang.AssertionError: **** Component reference function df:class#2 is already bound - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3645

closed

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

Added by Radu Coravu almost 7 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

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:

9.8.0.8

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

Copy link

Updated by Radu Coravu almost 7 years ago

File saxonicaBug.zip saxonicaBug.zip added

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

Actions

Copy link

Updated by Michael Kay almost 7 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

Copy link

Updated by Michael Kay almost 7 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

Copy link

Updated by Michael Kay almost 7 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

Copy link