Repository navigation
Breakpoints not hit. #12593
Description
Issue Type: Bug
I have a simple file parser in python and input text file. When I place a breakpoint at any line in the soure, the break point is not being hit.
I set the break point at line pointed to here. Or at any line for that matter...
if m1 != None: #program block begin
lnlst.append(line)
else: #existing list
if m1 is not None or m2 is not None: #program block begin or final block
for item in lnlst:
for fails in flist:
ptrn = "(\\"+fails[1]+")"+"(.*)" <<<<<<<<
match = re.search(ptrn,item)
if match != None:
errFound = True
[forcheck.zip](https://github.com/microsoft/vscode/files/4834297/forcheck.zip)
I expect the debugger to stop and allow me to inspect the variables.
I initially created a Microsoft bug for vscode and I was asked to submit this to vscode-python:
microsoft/vscode#101075
VS Code version: Code 1.46.1 (cd9ea6488829f560dc949a8b2fb789f3cdc05f5d, 2020-06-17T21:13:20.174Z)
OS version: Windows_NT x64 10.0.18363
System Info
| Item | Value |
|---|---|
| CPUs | Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz (12 x 2592) |
| GPU Status | 2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: enabled rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled |
| Load (avg) | undefined |
| Memory (System) | 31.72GB (15.84GB free) |
| Process Argv | |
| Screen Reader | no |
| VM | 0% |
Extensions (14)
| Extension | Author (truncated) | Version |
|---|---|---|
| vscode-markdownlint | Dav | 0.36.0 |
| xml | Dot | 2.5.0 |
| vscode-solution-explorer | fer | 0.3.10 |
| vscode-pull-request-github | Git | 0.17.0 |
| fortran-ls | han | 0.6.2 |
| linter-gfortran | krv | 2.2.1 |
| vscode-azureappservice | ms- | 0.17.0 |
| vscode-docker | ms- | 1.3.1 |
| python | ms- | 2020.6.90262 |
| remote-wsl | ms- | 0.44.4 |
| azure-account | ms- | 0.8.11 |
| cpptools | ms- | 0.28.3 |
| powershell | ms- | 2020.6.0 |
| sourcery | sou | 0.2.5 |
Output from Console under the Developer Tools panel (toggle Developer Tools on under Help; turn on source maps to make any tracebacks be useful by running Enable source map support for extension debugging)
XXXX
Activity
int19h commentedon Jun 26, 2020
How are you running the file? To hit breakpoints, you need to do Run -> Start Debugging (F5). If you're using "Run Python File in Terminal" on the editor toolbar, that does not run it in debug mode.
sachinmyneni commentedon Jun 26, 2020
Hello, I am running Run->Start Debugging
If I changed the python used to a different one (ActiveState 3.6.6), it works.
When I use the Anaconda provide 3.7.3 it fails.
int19h commentedon Jun 26, 2020
For Anaconda, try starting VSCode from a terminal in which the conda environment has already been activated manually - does that help?
sachinmyneni commentedon Jun 26, 2020
Yes!!
I just opened the Anaconda prompt and typed code start up VS code. Now the breakpoint is hit.
At this point if at the bottom I clicked on the python interpreter and changed it to the Activestate one, that hits the breakpoint too.
Interesting..
Do you suppose my %Path% has anything to do with it?
FWIW, this is from my Dos window, without starting Anaconda prompt:
Thank you
-Sachin
sachinmyneni commentedon Jun 26, 2020
Additional observations: As I am working and debugging with the anaconda-python, the breakpoint stops working again. I am still trying to debug using Run->Start Debugging as before.
Switching to the ActiveState Python didn't work. I close VSCode. Opened a new one again from the anaconda prompt and breakpoints are hit once again.
This happened a few times... I don't think I am doing anything weird each time.. just run->start debugging and stop-debugging when I want to make change to the python file. I even tried F5 command shortcut to do the same.
It seems to work for a while and then debugger stops hitting the breakpoint when I go run->start debugging (or hit F5). I just restart from the anaconda prompt and continue working.
serend1p1ty commentedon Jun 28, 2020
Pavel Minaev (@int19h) sachinmyneni
Hi, I have the same strange problem.
When I try to start debuging, the vscode look like this (Pay attention to the color of the status bar):
It does not hit any breakpoint.
But it works when I restart vscode.
By the way, the bug has no rules. I have no idea when or under what conditions it will appear. I just know that restarting is a solution.
int19h commentedon Jun 28, 2020
This is a general problem with Conda activation. We haven't been able to find a solution that works reliably so far, so for now, you have to use the workaround with manual activation.
If you watch the terminal closely, you'll see that it happens when the debugger command line (
... debugpy ...) overlaps with the conda activation command line (... conda activate ...). Hence why it's not deterministic.int19h commentedon Jun 29, 2020
One thing I forgot to mention - once you start VSCode from an already-activated terminal, you should also disable auto-activation for terminals in VSCode - this is "python.terminal.activateEnvironment".
Manual activation before starting VSCode + disabling auto-activate should provide a consistent workaround - please let me know if it still breaks for you.
serend1p1ty commentedon Jul 6, 2020
Pavel Minaev (@int19h)
Hi, I have some different thoughts from you.
Conda activation only happens when creating a new terminal, but you can see the breakpoints still will not be hit when I use an existing activated terminal (env torch1.2_py2 has been activated).
serend1p1ty commentedon Jul 6, 2020
BTW, I find switching debug configuration is a workaround.
Here is my configuration:
Pavel Minaev (@int19h) Maybe the issue should be open again?
sahiljuneja commentedon Aug 28, 2020
Pavel Minaev (@int19h) Just wanted to inform you that the workaround is not working.
int19h commentedon Aug 28, 2020
It sounds like there's a different issue here that might manifest with similar symptoms, but has a different root cause. The fact that switching configs makes some difference might be indicative of it being a bug in VSCode itself, in fact, so we might have to route it accordingly. So it would be best to file that as a separate issue.
chege54 commentedon Sep 16, 2020
Pavel Minaev (@int19h) I have found some similar behavior. I am using conda environment. I tried manual activation, or automatic, and beside of this created a new config, none of them worked.
The issue is: for me the breakpoints is hitted, but not all. I am placing more breakpoints in a file, so the first one is hitted but the others are not. Behavior is incosistent, so if I disable ex. the first all others are hitted.
leo-paz commentedon Jan 16, 2021
Can this be opened again? The workaround of not activating the python environment in the shell is not working and it is important for me to be able to debug the specific versions in my virtualenv