Project

Profile

Help

Bug #2173

closed

NullPointerException after inlining variables

Added by Michael Kay about 10 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
Start date:
2014-10-09
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

In a problem reported by Hans-Juergen Rennau on saxon-help list, followed up by private email, there were two occurrences of a problem that resulted from inlining of local variables:

The first two are very similar. They occur when inlining a variable declared in a FLWOR expression, for example $merge on line 51 of namesReporter.mod.xq. The inlining happens when a variable is declared and is only used once (and not in a loop): the effect is to eliminate the let clause from the FLWOR expression, and replace the variable reference by the expression to which it is bound. Before doing this, the expression is copied (the cases where this is necessary are rather obscure, but they do arise). The copy() operation is implemented separately for each expression, and it is intended to retain location information. But your query exposed two cases where location information was not being copied: the ItemChecker expression and a Switch expression (neither appear literally in the code, but are created by earlier optimizations). The location information includes a pointer to the containing function, and in the absence of this, a subsequent operation on the expression tree was failing.


Related issues

Related to Saxon - Bug #2218: ByteCode generation failure during compilation in 9.6ClosedO'Neil Delpratt2014-11-11

Actions
Actions #1

Updated by Michael Kay about 10 years ago

  • Status changed from New to Resolved

For 9.6, I have patched the copy() method of the two expressions where the problem occured: ItemChecker and Switch.

For 9.7, I have reviewed all implementations of the copy() method (over 140 of them) and have added a call to copyLocationInfo() to those where it was missing. This is belt-and-braces; it won't usually be necessary, because the way copyLocationInfo() works, information is passed beween parents and children on the tree so the code is generally fairly robust. However, we'll keep this under review, it may be prudent to change all implementations of copy() on the 9.6 branch as well.

Closing for now.

Actions #2

Updated by O'Neil Delpratt about 10 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in version set to 9.6.0.2

Bug fix applied to the maintenance release Saxon 9.6.0.2

Actions #3

Updated by O'Neil Delpratt almost 9 years ago

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

Please register to edit this issue

Also available in: Atom PDF