Wrong line number in IR

[svenkeidel]

📝 Overall Description

Tai-E computes the wrong line numbers for certain IR statements.

The problem occurs, for example, in Jasml (https://github.com/JavaQualitasCorpus/jasml-0.10) in method com.jasml.compiler.SourceCodeParser.parseMethod(), but the problem likely appears in other places too.

$ javap -private -verbose -cp jasml.jar com.jasml.compiler.SourceCodeParser
public class com.jasml.compiler.SourceCodeParser implements com.jasml.compiler.Scannable
  ...
  private com.jasml.classes.Method parseMethod() throws com.jasml.compiler.ParsingException, com.jasml.compiler.GrammerException;
    descriptor: ()Lcom/jasml/classes/Method;
    flags: (0x0002) ACC_PRIVATE
    Code:
      stack=7, locals=7, args_size=1
        ...
        91: invokespecial #333                // Method parseMethodInstructions:(Lcom/jasml/classes/Method;)Lcom/jasml/compiler/SourceCodeParser$LabeledInstructions;
        94: astore_2
        95: new           #335                // class com/jasml/classes/Attribute_Code
        ...

      LineNumberTable:
        ...
        line 92: 91
        line 95: 94
        line 96: 95
        ...

🎯 Expected Behavior

The line for the invokespecial at PC 91 should be 92.

🐛 Current Behavior

Tai-E computes a line number of 95 for the invokespecial:

World.get().getClassHierarchy().getClass("com.jasml.compiler.SourceCodeParser").getDeclaredMethod("parseMethod").getIR().getStmts().get(30)
-> "<com.jasml.compiler.SourceCodeParser: com.jasml.classes.Method parseMethod()>[30@L95] li = invokespecial this.parseMethodInstructions(method)"

🔄 Reproducible Example

Here are the jars which I used for this example: jasml.zip

I preprocessed the jars with a tool that gives each instruction its own unique line number based on the program counter of the instruction. This way it holds that line-number = program-counter + 1. You can use this as a test to check if you got it right.

⚙️ Tai-e Arguments

Main.main("-cp", "jasml/jasml.jar", "-cp", "jasml/entrypoint.jar",
                "-m", "Entrypoint",
                "-a", "pta")

📜 Tai-e Log

[Tai-e] starts ...
Output directory: Tai-e/output
Writing options to Tai-e/output/options.yml
Writing log to Tai-e/output/tai-e.log
java.version: 17.0.20.1
java.version.date: 2026-08-18
java.runtime.version: 17.0.20.1+1
java.vendor: Eclipse Adoptium
java.vendor.version: Temurin-17.0.20.1+1
os.name: Linux
os.version: 7.0.0-30-generic
os.arch: amd64
Available CPU cores: 14
Total memory: 31002MB
Tai-e Version: 0.5.5-SNAPSHOT
Tai-e Commit: 2c925c6b3b064ec54b3f95c386c17c87d04b39b1
Writing analysis plan to Tai-e/output/tai-e-plan.yml
[WorldBuilder] starts ...

6420 classes with 66297 methods in the world
[WorldBuilder] elapsed time: 0.18s; CPU usage: start 28.66%, peak 60.37%, end 85.80%; Memory usage: start 147MB, peak 201MB, end 243MB

ℹ️ Additional Information

No response

[svenkeidel]

By the way, we depend on the line numbers being correct because we use them in a precision/recall comparison with a dynamic call graph. We distinguish different call-sites within a method by their line numbers. Since line number by default may not be unique, we manipulate the line number table to be PC+1, such that the line numbers become unique. Currently, our comparison with the dynamic call graph shows a low recall for Tai-E, I suspect mostly because of the wrong line numbers. If we could get access to the program counter (bytecode offset) of the original instruction, this would also work.

[ayanamists]

Thanks for the report, and for the note about matching against a dynamic call graph.

I currently don’t think this is a bug. Tai-e’s new frontend emits a compact IR: bytecode and Tai-e statements are not 1–1. In your example

91: invokespecial parseMethodInstructions(...)
94: astore_2

are folded into a single statement

li = invokespecial this.parseMethodInstructions(method)

So this is essentially 2 bytecode instructions → 1 IR statement. If their LineNumberTable entries diverge (92 vs 95), we have to pick one, which may not be the line you want. Recovering line numbers here is best-effort, and probably not a good fit for using lines as unique call-site keys.

cc @zhangt2333 — two possible ways forward:

1. A flag to turn off this kind of compact IR, so producer and store stay as separate statements.
2. A new API that returns the set of line numbers { lns } folded into a statement, instead of a single getLineNumber().

[svenkeidel]

Thank you for the prompt response. I understand the problem.

Here is another solution that what would work for us:
If you merge 2 bytecode instructions into 1 IR statement, pick the line number of the invoke instruction.

[ayanamists]

Thank you for the prompt response. I understand the problem.

Here is another solution that what would work for us: If you merge 2 bytecode instructions into 1 IR statement, pick the line number of the invoke instruction.

Yes, i think we should also consider this.

[svenkeidel]

For your interest, here are the precision recall numbers for your context-insensitive PTA algorithm for jasml, where we only compare call edges where either the caller or the target are in the jasml package:

{
  "methods" : {
    "precision" : 0.8325791855203619909502262443438914,
    "recall" : 0.9945945945945945945945945945945946,
    "f1-score" : 0.9064039408866995073891625615763549,
    "true_positive" : 184,
    "false_positive" : 37,
    "false_negative" : 1
  },
  "edges" : {
    "precision" : 0.6930596285434995112414467253176931,
    "recall" : 0.9699042407660738714090287277701778,
    "f1-score" : 0.8084378563283922462941847206385403,
    "true_positive" : 709,
    "false_positive" : 314,
    "false_negative" : 22
  },
  "edges-with-callsite-line-numbers" : {
    "precision" : 0.1295764536970567121320890165111271,
    "recall" : 0.1872406639004149377593360995850622,
    "f1-score" : 0.1531607976240984302078913873568095,
    "true_positive" : 361,
    "false_positive" : 2425,
    "false_negative" : 1567
  }
}

As you can see, the edges.recall is a lot better because we do not distinguish call sites within a method, but join them.
Because of the wrong line numbers, the edges-with-callsite-line-numbers.recall is a lot lower.

If you want to debug, here are the false positives and false negative sets for Tai-E Taie-Jasml.zip and the dynamic call graph jasml-0.10-callgraph.csv.gz. In there are also files called false-negative-boundary. These files include the first false negative calls, but exclude transitively reachable false negative calls. If you want to work on false negatives, I would start here first.

[zhangt2333]

Thanks @svenkeidel for the report, and thanks @ayanamists for the prompt analysis and response.

We have just committed a fix to the latest branch. Could you please give it a try with the latest snapshot version (https://github.com/pascal-lab/Tai-e/releases/tag/v0.5.5-SNAPSHOT)?

[svenkeidel]

@zhangt2333, thank you for the quick fix. I will test it and get back to you.

[svenkeidel]

That worked!

{
  "methods" : {
    "precision" : 0.8325791855203619909502262443438914,
    "recall" : 0.9945945945945945945945945945945946,
    "f1-score" : 0.9064039408866995073891625615763549,
    "true_positive" : 184,
    "false_positive" : 37,
    "false_negative" : 1
  },
  "edges" : {
    "precision" : 0.6930596285434995112414467253176931,
    "recall" : 0.9699042407660738714090287277701778,
    "f1-score" : 0.8084378563283922462941847206385403,
    "true_positive" : 709,
    "false_positive" : 314,
    "false_negative" : 22
  },
  "edges-with-callsite-line-numbers" : {
    "precision" : 0.6597272074659009332376166547020818,
    "recall" : 0.9533195020746887966804979253112033,
    "f1-score" : 0.7798048366567670767925328807806535,
    "true_positive" : 1838,
    "false_positive" : 948,
    "false_negative" : 90
  }
}

The edges-with-callsite-line-numbers.recall improved from 18.7% to 95.3%.

Thank you very much for the quick response and fix. This is great user support!

[svenkeidel]

In case you want to investigate the remaining false negatives (or false positives), here are the results after the line number fix: tai-e-jasml-0.10.zip

I'll close this issue here.