Project

Profile

Help

Bug #2343

closed

IncompatibleClassChangeError

Added by O'Neil Delpratt over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Internals
Sprint/Milestone:
Start date:
2015-03-31
Due date:
% Done:

100%

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

Description

Reported by user:

The following error occurs when the bytecode generation feature is on:

Exception in thread "main" java.lang.IncompatibleClassChangeError: Class net.sf.saxon.value.StringValue does not implement the requested interface net.sf.saxon.om.NodeInfo

       at EE_main_01585635178.process(file:/P://test.xsl:22)

       at com.saxonica.ee.bytecode.CompiledExpression.process(CompiledExpression.java:66)

       at net.sf.saxon.expr.instruct.Template.expand(Template.java:373)

       at net.sf.saxon.Controller.transformDocument(Controller.java:2119)

       at net.sf.saxon.Controller.transform(Controller.java:1705)

       at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:547)

       at net.sf.saxon.Transform.processFile(Transform.java:1056)

       at net.sf.saxon.Transform.doTransform(Transform.java:659)

       at net.sf.saxon.Transform.main(Transform.java:80)
Actions #1

Updated by O'Neil Delpratt over 9 years ago

Similar error in the interpreted code:

java.lang.ClassCastException: net.sf.saxon.value.StringValue cannot be cast to net.sf.saxon.om.NodeInfo
	at net.sf.saxon.functions.KeyFn.iterate(KeyFn.java:276)
	at net.sf.saxon.expr.Atomizer.iterate(Atomizer.java:319)
	at net.sf.saxon.expr.AtomicSequenceConverter.iterate(AtomicSequenceConverter.java:244)
	at net.sf.saxon.functions.FoldingFunction.evaluateItem(FoldingFunction.java:56)
	at net.sf.saxon.expr.Expression.evaluateAsString(Expression.java:533)
	at net.sf.saxon.expr.instruct.SimpleNodeConstructor.processLeavingTail(SimpleNodeConstructor.java:230)
	at net.sf.saxon.expr.instruct.ValueOf.processLeavingTail(ValueOf.java:282)
	at net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:672)
	at net.sf.saxon.expr.instruct.Template.expand(Template.java:371)
	at net.sf.saxon.Controller.transformDocument(Controller.java:2119)
	at net.sf.saxon.Controller.transform(Controller.java:1705)
	at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:547)
	at net.sf.saxon.Transform.processFile(Transform.java:1056)
	at net.sf.saxon.Transform.doTransform(Transform.java:659)
	at net.sf.saxon.Transform.main(Transform.java:80)
Actions #2

Updated by O'Neil Delpratt over 9 years ago

  • Subject changed from ncompatibleClassChangeError in bytecode generation to IncompatibleClassChangeError
  • Category changed from Byte code generation to Internals
  • Status changed from New to Resolved
  • % Done changed from 0 to 100

A fix has been applied to the OptimizerEE class where we create the KeyDefinitions to do a deep copy of the path expressions. The problem was that the slot numbers for the variable bindings where being incorrectly overwritten during the allocation of slot numbers for the KeyDefinition.

Bug fix committed to the 9.6 and 9.7 branches.

Actions #3

Updated by Michael Kay over 9 years ago

Just for the record: there's a fairly convoluted path here from cause to effect.

There's a filter expression of the form $doc/a/b/c[d='f'] where $doc is a reference to a global variable. The optimizer turns this into a call on key(), and constructs a key definition that indexes $doc on the value of /a/b/c. Both the call on key() and the key definition include references to $doc, but instead of containing separate variable references, they share the same variable reference. But because the template and the key definition are separate components, they each need a separate binding slot for this global reference. So one of the slot numbers is wrong, which means that when the key() call is evaluated, the wrong global variable is read, and this has the wrong type, which causes a cast to fail during evaluation of generated byte code. When byte code is switched off, it fails with slightly different symptoms. The solution is to create a copy of the variable reference rather than sharing it.

Actions #4

Updated by O'Neil Delpratt over 9 years ago

  • Status changed from Resolved to Closed
  • Fixed in version set to 9.6.0.6

Bug fix applied in the Saxon 9.6.0.6 maintenance release.

Actions #5

Updated by O'Neil Delpratt about 9 years ago

  • Sprint/Milestone set to 9.6.0.6
  • Applies to branch 9.6 added
  • Fix Committed on Branch 9.6 added
  • Fixed in Maintenance Release 9.6.0.6 added

Please register to edit this issue

Also available in: Atom PDF