Project

Profile

Help

Bug #4089

TinyTree bulk copy fails with AssertionError when copying final empty element node

Added by Michael Kay about 3 years ago. Updated over 2 years ago.

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

100%

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

Description

A copy-of() operation that copies nodes from one TinyTree to another is optimized to perform a bulk copy (think Array.copy(), except that adjustments are needed for example to node depth).

This bulk copy operation is failing (with an AssertionError) if the element to be copied is the last one in the tree, that is, it has no following siblings and no children, and none of its ancestors have a following sibling or further children.

History

#1 Updated by Michael Kay about 3 years ago

  • Status changed from New to Resolved

I'm not sure exactly why it happens but for the moment I've patched it so the optimized copy is disabled in this situation (patch to TinyElement.tryBulkCopy())

#2 Updated by Michael Kay about 3 years ago

  • Status changed from Resolved to In Progress

I have found another case where bulk copy fails. In this case there is no exception, the symptom is that the result tree after the copy is missing some elements.

The problem occurs when using the XX-compiler (a rather complex stylesheet) to transform test case import-0201

#3 Updated by Michael Kay almost 3 years ago

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

I believe I have now tracked this down. The problems occurred when the "stopper" node from the source tree was being copied. It seems that sometimes the "numberOfNodes" property of a tree includes the stopper node, and sometimes not, depending perhaps on whether close() was called on the tree or not. I've adjusted the code for bulk copy so it caters for both possibilities, and this seems to resolve the issue. The problem was only known to occur when running the XX compiler, and that is now running on Saxon 9.9 with no problems. I am therefore removing the flag that disables the bulk copy feature.

#4 Updated by O'Neil Delpratt over 2 years ago

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

Bug fix applied to the Saxon 9.9.1.3 maintenance release

Please register to edit this issue

Also available in: Atom PDF