Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #4089

closed

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

Added by Michael Kay over 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Michael Kay
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:
9.9.1.3
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.

Actions
Copy link
 #1

Updated by Michael Kay over 5 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())

Actions
Copy link
 #2

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

Actions
Copy link
 #3

Updated by Michael Kay about 5 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.

Actions
Copy link
 #4

Updated by O'Neil Delpratt almost 5 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

Actions
Send by e-mail Copy link

Also available in: Atom PDF