eclipse-jdt / eclipse.jdt.debug

Eclipse Public License 2.0
16 stars 46 forks source link

Debug tooltip contains wrong variable reference for inherited methods #396

Open bobcristian996 opened 6 months ago

bobcristian996 commented 6 months ago

Hello!

When I hover over a variable, the variable's reference is different from the one shown in the Variables view. The correct reference is shown by the Variables view. This happens when the calling method is inherited.

Expected Behavior

The debug tooltip should contain the same information as the Variables view.

Steps to Reproduce

  1. Download the attached mock Java project (com_amiq_jdt_bug.zip)
  2. Add a breakpoint at line 30 (i.e. element.iterateElements()) in the Element.java file
  3. Run the example in debug mode
  4. The issue appears when the debugger stops in a calling method inherited by a subclass (the second and third breakpoint stops)

Context (Environment)

Tested eclipse SDK versions: E4.19, E4.22, E4.24, E4.28, E4.30 (latest) Eclipse JDK: GraalVM 17.0.3+7-jvmci-22.1-b06 Project execution environments: GraalVM 17.0.3+7-jvmci-22.1-b06, OpenJDK 1.8.0_322 OS: Ubuntu 22.04 Arch: x86_64 GTK: 3.24.33 VM Args: -Xmx 4G

Detailed Description

This project consists of 3 classes and an interface:

The Element class contains a public field of type IElement called element, and implements the iterateElements() method which goes recursively down in the hierarchy and prints something in the console.

The Main.main() function contains a chain of 4 IElement objects which in a top-bottom hierarchy view look like this:

  1. Element
  2. SamePkgElement
  3. OtherPkgElement
  4. Element

When adding a breakpoint in the Element.iterateElements() method, the second time (i.e. from the SamePkgElement) and the third time (i.e. from the OtherPkgElement) the debugger stops at this breakpoint, and when hovering over the element field, its reference shown in the tooltip differs from the one in the Variables view. You can see that in the snapshots below:

image (2)

image (1)

The first time and the last time the debugger hits that breakpoint, the value is correct. The problem seems to be only when the calling method is inherited.