Debugger is using old cached test file

[IzakMarais]

When I set a breakpoint and use the debugger, it opens an old cached version of the source file

Environment

• Operating System: Windows 8 and 10 (recently upgraded, got the same issue on both)
• JDK version: java version "1.8.0_162"
  Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
• Visual Studio Code version: 1.23.1
• Java extension version: Java extension pack 0.3.0
• Java Debugger extension version: 0.9.0

Steps To Reproduce

1. Check out a simple single module maven project.
2. Set a breakpoint in VSCode in one of the tests.
3. Use mvn -Dmaven.surefire.debug test to run the test. Stops at Listening for transport dt_socket at address: 5005
4. Attach the debugger to port 5005. Everything works fine the first time.
5. Continue working on the project (edit, compile, test code). Possibly days later run the debugger again using the same workflow.
6. It uses an old cached file. The actual source file: (Note the file path and breakpoint at line 280)
   
   Cick on top call stack item in vscode debug panel shows some older cached version of the file (note file path in AppData/Local/Temp):
   

This used to work fine a couple of months ago.

[yaohaizh]

@testforstephen, we need take a look at the source mapping container in the attach scenario.

[testforstephen]

@IzakMarais The java debug extension doesn't cache your java files to some temp directory. Not sure where it comes from. Can you share why there are cached versions in your environment?

[IzakMarais]

I have no idea, maybe it's something that maven surefire does? But how would the debugger know to open that file? What might I do to debug it further?

[testforstephen]

The debugger will ask the language server to get the source mapping (file <-> class) for current hitting location. And the source mapping relationship is built up by java language server when your workspace is loaded to VS Code. Could you remove the cached directory and try again?

[IzakMarais]

Prior to deletion there seems to be mulitple directories in the Temp folder that have been created:

After deleting them all and rerunning the debugger, it seems that it is still trying to access one of the old deleted files:

I also closed the workspace in VSCode and reopened it to see if restarting the java language server this way would solve the problem. It still tries to fetch the now-deleted file.

[IzakMarais]

I've tried searching the workspace for a file where this source mapping might be cached, but have not managed to find anything.

[testforstephen]

The cached source mapping is placed at the directory C:\Users\jinbwan\AppData\Roaming\Code\User\workspaceStorage, cleaning up it will remove the cached data.

[IzakMarais]

Great. I can confirm that after:

1. closing VSCode,
2. deleting the workspaceStorage sub directory associated with the workspace in question,
3. reopening the workspace in VSCode,
4. retrying the debugger at the same breakpoint,

it works correctly and attaches to the correct version of the file where the breakpoint is set.

So the question becomes why is this manual intervention necessary?

[testforstephen]

It looks like a bug at the underlying language server service. It caches external java files (don't belong to current vscode workspace folder) to current workspace mistakenly. If you could provide the reproduce steps, that would be helpful for us to investigate.

[IzakMarais]

After switching to a new computer, and working in a different repository for a couple of months, this behaviour appeared today. So it seems very intermittent and difficult to reproduce.

[yahuio]

I'm encountering the same issue is there anyway to workaround? where's the cache location for ubuntu?

[andxu]

see microsoft/vscode#3884 for workspaceStorage in ubuntu

[emadams93]

I am having the same problem in Visual Studio. It has happened a few times today. I am debugging code that I edited, but it keeps running the same code over and over, no matter what change. I even commented out a bunch of code, I set break points, and it just runs right through with the old code.

[emadams93]

Since I am connecting to a database to extract data to some variables in the program, and this seems to be where the hangup is occurring, I intentionally changed the password to throw an error connecting to the database, and then when I changed the password back it works again after that.

[emadams93]

And it just happened again, and this time I changed the password to connect to the database to an incorrect password, but it is still running the code before the same as before the changes were made.

[yaohaizh]

could you invoke "Java: Clean the Java language server workspace" command or "Java: Force Java Compilation" to see whether fix this problem?

[Izhaki]

Same issue... Prettier did some formatting (1 line > 4 lines) and all my previously set breakpoints are now 3 lines early on that file.

[akaroml]

@testforstephen any updates for this?

[akougblenou]

any update on this, I am facing the same issue and I am running on a mac 2020, with BigSur.

[rosesonfire]

Any update on this?

[rosesonfire]

This worked for me.

Adding this task in .vscode/tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "clear-editor-history",
      "command": "${command:workbench.action.clearEditorHistory}"
    }
  ]
}

And using the task in launch configuration (.vscode/launch)

{
  "version": "0.2.0",
  "configurations": [
    {
      ...
      "preLaunchTask": "clear-editor-history"
      ...
    }
  ]
}

[fredg1]

Well this is awkward... I came here specifically to report that preLaunchTasks and postDebugTasks that modify a Java file aren't being picked up by the debugger, and the last post I see on an issue that seems to match this problem proposes using a preLaunchTask ...

[ChuhC]

The cached source mapping is placed at the directory C:\Users\jinbwan\AppData\Roaming\Code\User\workspaceStorage, cleaning up it will remove the cached data.

this works for me。 it's weird, the result is different with or without breakpoints

[kzhui125]

I meet this issue too:

[kzhui125]

I want to debug /home/ubuntu/source/test/QuickStart.java

but the debugger try to debug files in /home/ubuntu/.vscode-server/data/User/workspaceStorage/052d2585193dcc6cf9345bedcec13d13

[kzhui125]

I want to debug QuickStart.java, why does the extension debug 9rWa.java?

the extension is unusable!!

3.gif.zip

[pedrobbarbosa]

Looks like the solution is what colleagues have commented on earlier. We need to delete the files cached by vscode in the workspacestorage and tmp folders, this fixes it for a while, but the problem eventually returns.

Has a definitive solution been released to resolve this issue?