Python 3.8 Debugger frame not available

PyCharm 2019.3.4 and Python 3.8

Line-by-line debugging and breakpoints work until a certain point. After a certain class method is called, it shows "frame not available", and even though the stepping commands work, the screen isn't updated. After downgrading to Python 3.7, it works fine.

15 comments
Comment actions Permalink

Is there a chance you can share a code that we can use to reproduce this?

0
Comment actions Permalink

Unfortunately, no. Sorry. I find this very weird. I have this project in PyCharm that was working fine with Python 3.8. Debugger worked fine. This morning, I updated my packages and it stopped working. But if I install Python 3.7 in the environment, the debugger works fine. After switching back to Python 3.8, I get the same problem.

0
Comment actions Permalink

Does the issue reproduce in a brand new project but with exactly the same 3.8 interpreter you use in your current project?
If not, then perhaps it's a code-specific issue.

0
Comment actions Permalink

I just removed the project from Project View, deleted the .idea directory, and recreated the project. Still have the same problem at the same line.

The main file looks like this:

from mymod import MyClass


def main():
myobj = MyClass()

# If I put a breakpoint on the next line and try to Step In, I get the "frame not available" problem
myobj.method1()


if __name__ == "__main__":
main()

In the code above, `MyClass` extends an abstract class (I'm using `from abc import ABC`). Again, it works fine with Python 3.7.

0
Comment actions Permalink

Works fine with my code snippets.

Let's see if we can troubleshoot it without a code sample. Add PYCHARM_DEBUG=True environment variable to your run configuration, reproduce the problem, then file an issue to https://youtrack.jetbrains.com/issues/PY and provide the whole console output you got.

0
Comment actions Permalink

OK, I see a difference between 3.7 and 3.8 in the PyCharm debug message.

In Python 3.7, I have:

sending cmd --> CMD_THREAD_SUSPEND <xml><thread id="pid_12864_id_1543714442568" stop_reason="107" message="" suspend_type="trace"><frame id="1543764149736" name="optimize" file="D:\Projects\Program\MyProject\simulator\simulator\code\mymod.py" line="221"></frame><frame id="1543733278728" name="main" file="D:\Projects\Program\MyProject\simulator\simulator\code\example1.py" line="14"></frame><frame id="1543711783416" name="&lt;module&gt;" file="D:\Projects\Program\MyProject\simulator\simulator\code\example1.py" line="22"></frame></thread></xml>

The equivalent line in Python 3.8 is:

sending cmd --> CMD_THREAD_SUSPEND <xml><thread id="pid_12968_id_2377292837600" stop_reason="107" message="" suspend_type="trace"><frame id="2377340301856" name="optimize" file="C:\virtpart\drive.d\projects\program\myproject\SIMULA~1\SIMULA~2\code\mymod.py" line="221"></frame><frame id="2377292123600" name="main" file="D:\Projects\Program\MyProject\simulator\simulator\code\example1.py" line="14"></frame><frame id="2377311563104" name="&lt;module&gt;" file="D:\Projects\Program\MyProject\simulator\simulator\code\example1.py" line="22"></frame></thread></xml>

Why is the bold part happening with 3.8? Why is D: treated as C:\virtpart\drive.d in Python 3.8?

0
Comment actions Permalink

Just wanted to emphasize that the stepping does work. New variables are populated as I step in the debug. The only problem is that the screen isn't updating as I step through the code. It remains in the first screen. Every level deeper I go in the debugging, I get more <frame not available> under Frames.

0
Comment actions Permalink

Sergey Karpov, did you have a chance to look into this? I've been using Python 3.7 because I do need a fully functioning debugger. Otherwise, I'd be using Python 3.8. Thanks!

0
Comment actions Permalink

Is D drive physically a different hard drive or is it virtual or a network mount?

Are there any symlinks?

0
Comment actions Permalink

I believe it's a local virtual drive. It's not network or remote. It takes up the same space as the C drive. So I believe there's only one physical drive.

It seems that PyCharm is getting "confused" with the C:\virtpart\drive.d address when an interpreter using Python 3.8 is used in a project. But the same IDE version works fine with Python 3.7.

0
Comment actions Permalink

Does it work fine with Python 3.8 if you move the project to C drive?

0
Comment actions Permalink

Yes, I confirmed that opening a project from C (e.g., my Desktop directory) works fine with Python 3.8. But that's not really an option for me as I'm supposed to keep data in D and installed software in C. I'm hoping that PyCharm will handle this situation with an update. :)

0
Comment actions Permalink

Hmm, I can't reproduce it.

How did you create that VHD?

Where are Python 3.7 and Python 3.8 interpreters you use in PyCharm located in the system? Are they in totally different locations?

In my case, they are both at C:\Users\username\AppData\Local\Programs\Python

0
Comment actions Permalink

I didn't create it. It's a work laptop and I have no power over it. It seems that PyCharm (or Python 3.8?) is using the actual folder of the virtual drive as C:\virtpart\drive.d instead of itself as D.

It's the same Anaconda environment installed under C:\Users\username\AppData\Local\Continuum\miniconda3\envs. If I do "conda install -n myenv python=3.7", I have no problems with the debugger. But if I do "conda install -n myenv python=3.8", I have the problem described above.

0
Comment actions Permalink

Problem was "fixed" by moving the project to the C drive. I tried every combination (installed Anaconda and PyCharm on C and D drives), but the only one that worked was if the project is in the C drive. My D drive is a virtual partition. And it seems that PyCharm doesn't like that. It keeps replacing D:\... with C:\VirtPart\drive.d\.... It's not a Python version issue.

0

Please sign in to leave a comment.