Remote debugger breakpoints do not stop until the file has been touched

Pycharm version: 2020.3.3

OS: macOS Big Sur (11.1)

I am experiencing inconsistent breakpoint behavior when using a docker image as the Python interpreter and debugging unit tests. I suspect it is specific to the use of the remote debug server under the hood in this configuration - I do *not* experience this when debugging against a python environment native to the host.

After going through some of the similar existing posts and trying various workarounds to no avail, I eventually made a remarkable discovery by experimentation that I hope will be specific enough to facilitate tracking down the root cause (and which also provides me a de facto workaround, albeit an unsatisfying one). My experiment goes like this

  • I open up a test file in my project that I haven't visited before
  • Set a breakpoint in a test
  • Click "debug". for the test
  • The test runs to completion without hitting the debugger - I can repeat, set more breakpoints on other lines, etc but none will stop
  • Touch the test file in the filesystem, i.e. `touch tests/foobar.py` from a separate console window
  • Click debug again
  • Now all breakpoints in the file are respected!

I'd tried invalidating the cache, recreating my project, restarting PyCharm, but the state is preserved across all of these (in the sense that a once-touched file continues to respect breakpoints). So I suspect it is really just a question of the timestamp on the file. For additional confirmation I tried another experiment - setting the file's timestamp back to what it was before, i.e. ` touch -m -a -t "202102090925" tests/foobar.py`, which causes the breakpoint to stop working again.

Hoping that analysis is informative enough to find a proper explanation and save someone else from the confusion I just went through!

2 comments
Comment actions Permalink

Very strange indeed. 

Could you submit an issue to https://youtrack.jetbrains.com/issues/py with the following data:

- Logs from **Help | Collect Logs and Diagnostic Data**

- Add `PYCHARM_DEBUG=True` env variable to your run/debug configuration, reproduce the issue and provide full debug console output.

0
Comment actions Permalink

Unfortunately I had to blow away the git clone I was working out of for unrelated reasons in the intervening couple days. I'm kicking myself for not making a copy in the state that it was in, since surely there's some additional relevant factor besides timestamps. I'll keep an eye out if I see it again.

I did mean to file an issue rather than creating a post. Apologies. Guess I clicked through the wrong workflow. Delete this or not as you see fit, and I'll open a proper ticket if I am able to repro.

0

Please sign in to leave a comment.