Project

Profile

Help

Bug #2496

closed

Incorrect tracing line number for LocalVariableReference and VariableReference

Added by Grzegorz Ligas over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Diagnostics
Sprint/Milestone:
-
Start date:
2015-11-14
Due date:
% Done:

0%

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

Description

Hi,

I'm using tracing to identify number of line that given expression is on.

In most cases everything is fine apart form LocalVariableReference (and based on a brief look on the code also VariableReference).

Easy way to reproduce this is to have the main file prepared like below:

declare function local:a() {

let $a := 'a'

return $a

};

local:a()

and have an instance of TraceListener configured that has a method enter() like below:

@Override

public void enter(InstructionInfo instructionInfo, XPathContext xPathContext) {

    System.out.print("enter " + instructionInfo.toString());

    System.out.println(" line: " + instructionInfo.getLineNumber());

    System.out.println(" constructType: " + instructionInfo.getConstructType());

}

With this in place just running the sample main file will show that the line with return (constructType: 2014 = RETURN EXPRESSION) is shown with line number of the closing curly brace instead of the line where the return actually is.

I've been able to fix the issue locally (don't know if this is a proper solution though) on Saxon by adding the typical construct of first capturing the offset (on the beggining of the method) and use it to set location at the end.

Please find the diff and the modified file version attached.

Saxon versions affected: 9.5.1.10, 9.6.0.7 (actually all versions that I could find)

Saxon version with fixed issue (attached file): 9.6.0.7


Files

XPathParser.java.diff (241 Bytes) XPathParser.java.diff Diff file Grzegorz Ligas, 2015-11-14 03:35
XPathParser.java (130 KB) XPathParser.java Complete file with fix Grzegorz Ligas, 2015-11-14 03:35
Actions #1

Updated by Michael Kay over 8 years ago

  • Status changed from New to Resolved

I've taken an opportunity for a general review of this area (in the 9.7 code base) and found quite a few cases where we haven't been following the protocol of saving the offset at the start of the expression - in particular I don't think there's been any systematic attempt to do this for single-token expressions such as variable references, so in these cases the location data will often be the start of the next expression. I've improved the situation for 9.7, though there are stlll a few cases where the results are questionable, especially where we're already well into reading the expression before we decide what kind of expression it is. The location information is only intended to be approximate. So I think I'm not going to do any selective patching on the 9.6 base (apart from anything else, I don't want to disturb any code in debuggers that is already making adjustments to our location information). But thanks for pointing it out, and 9.7 will be a bit better.

Actions #2

Updated by O'Neil Delpratt about 8 years ago

  • Status changed from Resolved to Closed
  • Applies to branch 9.6, 9.7 added
  • Fix Committed on Branch 9.7 added

Please register to edit this issue

Also available in: Atom PDF