Hitting a breakpoint opens a new instance of the file

[DeshmukhMalhar]

This issue is same as microsoft/vscode-python#5139, microsoft/vscode-python#225 and microsoft/vscode-python#4166
which closed and those suggest updating python ext, but mine is already up to date[2020.2.63072].

Issues microsoft/vscode-python#5049 and microsoft/vscode-python#1313 are similar in nature.

and no, This is not the case of lowercase drive letters as said in microsoft/vscode-python#2976 (comment)

The problem here is that the breakpoints if marked in the original file, are carried over but can't be disabled from the new file. As well as breakpoints created in the new file are not migrated back to original file. i.e. the breakpoints are treated different.

This leads to confusion in debugging as you just cannot see why the debugger is halting
If I want to remove a breakpoint, I have to use the breakpoints explorer.

This is the look of breakpoints explorer in debugger

And by habbit , assuming that the file being debugged is displayed, I start editing the file and save it, which propagates the contents to the original file, but the breakpoints in the original file are now ordered very differently, thus making the debugger stop everywhere. Which is just annoying.

The steps to reproduce the issue are mentioned here :
microsoft/vscode-python#225 (comment)

and examples are here :
microsoft/vscode-python#4166 (comment)

However, When I created a new Project, I was unable to produce the same result.
Then I thought that It may be because I have multiple Launch configurations in my project,
but testing with two launch configs in the new project does not seem to reproduce the issue.

I will try to provide as much info I can on this

The python interpreter is a conda env and code was started from conda powershell prompt in both cases

System Info:

AMD R7 1700 @3ghz
RAM 16GB, 52% usage
Multiple HDDs and SSDs
VSCode version 1.42.1

Python Extension version : 2020.2.63072

conda_problem_env_packges_installed.txt

EDIT:
UNRELETED:
Why is Github linking /pull/1313 at microsoft/vscode-python#1313 ?

Where it links /issues/# everywhere else?

[fabioz]

@DeshmukhMalhar do you have some kind of symlink or a subst drive there? Are you using a pytest run?

[int19h]

The breakpoint misbehavior is fundamentally an issue with VSCode itself treating the two tabs as two different files, even though they're really the same. Changes in the editor propagate from one tab to the other, because they flow through the file itself. But breakpoints are metadata, and don't get the same accidental sync. But, in any case, the real problem is that the extra tab shows up in the first place, so let's try to figure that one out first!

Since you can repro it in one workspace but not another, it's likely to do with configuration. Can you please share the debug configuration from launch.json that you're using when the bug happens, and also the one for the project where things work fine?

Also, if you're using an "attach" configuration, then the command line used to start ptvsd would also come in handy.

[fabioz]

p.s.: I'm asking about pytest specifically because it has an issue where it changes the working directory by resolving symlinks and substed drives, so, this could explain the issue... (see: pytest-dev/pytest#5965)

[DeshmukhMalhar]

@DeshmukhMalhar do you have some kind of symlink or a subst drive there? Are you using a pytest run?

no symlink or subst.
I am not using pytest run

Here is a snippet of my launch.json

The breakpoint misbehavior is fundamentally an issue with VSCode itself treating the two tabs as two different files, even though they're really the same. Changes in the editor propagate from one tab to the other, because they flow through the file itself. But breakpoints are metadata, and don't get the same accidental sync. But, in any case, the real problem is that the extra tab shows up in the first place, so let's try to figure that one out first!

Since you can repro it in one workspace but not another, it's likely to do with configuration. Can you please share the debug configuration from launch.json that you're using when the bug happens, and also the one for the project where things work fine?

Also, if you're using an "attach" configuration, then the command line used to start ptvsd would also come in handy.

the real problem is extra tab appearing.

Here is the command launching ptvsd

[DeshmukhMalhar]

After 12 days from my reply, I don't see any updates.
Am I supposed to do anything more?

[karthiknadig]

@DeshmukhMalhar sorry for the delayed reply. I think at this point we will need a way to repro this locally. If possible please share a minimal repro.

[DeshmukhMalhar]

I tested this with another python file in the same project, and I the tab duplication does not happen for it. I don't know why.

Steps To reproduce :

1. Open a python file in vscode
2. Set some breakpoints
3. Start debug by pressing F5
4. I don.t know if a custom launch config makes any difference or not, but here is mine:
   

there are two args if it helps

What should happen :

The debugger should start stepping through the same file on which it was launched on, not create a new file/tab.

[int19h]

Are there any differences between the file for which you are seeing double tabs, and the one for which it doesn't happen? E.g. anything unusual about the filename, or a different path?

Perhaps there's any difference in which those files are getting executed by your main script? E.g. one is imported, and the other one is execfile()'d, or something similar?

[fabioz]

@DeshmukhMalhar can you provide the logs for a session run where you have breakpoints in both versions of the file and it opens both after breakpoints hit?

Some notes on how to do that:

1. Please make sure that you're using the latest version of the debugger (see: Using latest version of the debugger. #2104 to check how to do that).

2. Make a debug run and provide the logs.

i.e.:

• Open VS Code
• Select the command Extensions: Open Extensions Folder
• Locate the Python extension directory, typically of the form ms-python.python-2020..***
• In that directory ensure you do not have any debug*.log files, if you do, please delete them
• Go back into VS Code and modify your launch.json to add the setting "logToFile": true, see below:

"version": "0.2.0",
"configurations": [
    {
        "name": "Python: Current File (Integrated Terminal)",
        "type": "python",
        "request": "launch",
        "program": "${file}",
        "stopOnEntry": true,
        "console": "integratedTerminal",
        "logToFile": true
    },

• Start debugging
• When done, go back into the extension directory and upload the file debug*.log into this GitHub issue.

[int19h]

We can't reproduce, so without the logs this isn't actionable. Please re-open if you're still having this problem and can share the logs.