Repository navigation
Inconsistent drive letters in debugger breaking Python debugger #67523
Description
- VSCode Version:1.30.2 (& latest insiders)
- OS Version:Windows
- Users use the token
${workspaceFolder}in ourlaunch.json - This gets translated by VSC to upper case drive letters
- This information is sent to the remote python debugger
- When adding breakpoints, VSC uses lower case drive letters and sends paths over the protocol as lower case drive letters.
- In both cases, VSC is involved and the extension is not provided any paths.
- As
${workspaceFolder}ends up being translated to upper case drive and this is sent to the remote debugger, and when breakpoints are added by VSC, VSC sends lower case drive letters. - As a result of this, breakpoints do not work = debugger doesn't work.
I've traced the problem to the fact that the ConfigurationResolverService is inheriting the AbstractVariableResolverService which in turn normalizes the drive letters to uppercase using code from labels.ts. I.e. we're resolving variables with logic used for display purposes.
Work around in Python Extension
- The only temporary solution we have for the python extension is to create a hook for the
resolveDebugConfigurationand replace all${workspaceFolder}tokens manually with a lower case drive letter. - However this is a work around and doesn't feel right.
Activity
DonJayamanne commentedon Mar 30, 2019
Andre Weinand (@weinand) ping as a reminder, I think you may have missed this, may not have been triaged.
weinand commentedon Mar 30, 2019
Depending on how the Python program is launched (within VS Code or outside VS Code in a terminal), the Python runtime might run with a lower case or upper case drive letter. So even if VS Code by itself tries to be consistent with drive letter casing, there are situations where drive letter casing is inconsistent. So the correct way to deal with this situation is by making the DA agnostic to drive letter casing. This is the approach node-debug is using.
DonJayamanne commentedon Apr 4, 2019
Majority of the time, the Python program is launched from the integrated terminal.
Not sure how this will help. The problem is DA will send back a stack trace with the path to the file, and then VSC will open that file, but if the drive letter casing is different, then we end up with a duplicate window.
Question
hack) in the DA to always return lower case drive letters when returning paths.auchenberg commentedon Apr 8, 2019
Andre Weinand (@weinand) In today's sync with the Python team we talked about this issue, and Don Jayamanne (@DonJayamanne) had put together this simple repo in VS Code.
Try opening on Windows:
And you'll see VS Code handling the same file as two different ones in each their editor, but the explorer treats it as the same file.
In the meeting it was mentioned that Visual Studio asks the underlaying filesystem on the casing for a particular file and uses that casing regardless of how it was opened into the editor.
Thoughts? Martin Aeschlimann (@aeschli)
microsoft/ptvsd#1313 (comment)
weinand commentedon Apr 9, 2019
I've created #71982 because this is independent from debugging.
The debt item behind that is #12448.
bpasero commentedon Jul 5, 2019
Don Jayamanne (@DonJayamanne) why exactly does the drive letter case have an impact on breakpoints working in Python or not? is that under your control or something within the Python debugger?
DonJayamanne commentedon Jul 5, 2019
So now the DA gets paths with upper and lower case drive letters! And this cause problems.
Basically debugger don't work
bpasero commentedon Jul 5, 2019
why? does the debugger make assumptions about the drive letter?
weinand commentedon Jul 5, 2019
Benjamin Pasero (@bpasero) please see what I learned from other debuggers: #12448 (comment)