Project

Profile

Help

Bug #2573

closed

IncompatibleClassChangeError from bytecode implementing for-each-group()

Added by Vinit Varghese almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Byte code generation
Sprint/Milestone:
-
Start date:
2016-01-06
Due date:
% Done:

100%

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

Description

IncompatibleClassChangeError when xsl:sort inside a for-each-group when byte-code generation is enabled.

Please check http://stackoverflow.com/questions/34623667/xslsort-inside-for-each-group for more details


Files

a.xml (274 Bytes) a.xml Vinit Varghese, 2016-01-07 01:07
a.xsl (910 Bytes) a.xsl Sample XSL Vinit Varghese, 2016-01-07 01:07
Actions #1

Updated by Michael Kay almost 9 years ago

  • Category set to Byte code generation
  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal
  • Applies to branch 9.7 added

Thanks for reporting it. I have reproduced the problem, and have confirmed that it goes away if bytecode generation is disabled (which provides a workaround).

Actions #2

Updated by Michael Kay almost 9 years ago

  • Subject changed from xsl:sort inside for-each-group() to IncompatibleClassChangeError from bytecode implementing for-each-group()
  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.7 added

The problem has been fixed by a simple patch to ForEachGroupCompiler. It is another instance of a common bug that arose after we refactored Expression to no longer implement Location, but instead to have a getLocation method: in some cases IntelliJ's automatic refactoring added a getLocation() call inappropriately. In most cases Java's static typing detected this, but when it happened in bytecode generation the error is generally at execution time.

What's interesting now is the fact that this went undetected. A supplementary answer on the original StackOverflow report shows that the problem goes away if a call to current-grouping-key() is added to the stylesheet. It turns out that the expression implementing current-grouping-key() is not capable of generating bytecode, and the same is true for current-group(), which means that in nearly all cases the attempt to generate bytecode for an xsl:for-each-group instruction fails. The failure is silent and results in fallback to interpreted execution, which is why none of our tests picked up this issue.

I'm going to mark this issue as solved, and raise a new issue on the fact that bytecode isn't being generated for these function calls.

Actions #3

Updated by O'Neil Delpratt almost 9 years ago

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

Bug fix applied in the Saxon 9.7.0.2 maintenance release

Actions #4

Updated by O'Neil Delpratt almost 9 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF