Python 3.8 Debugger frame not available

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

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.

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.

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.

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.

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?

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.

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!

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

Are there any symlinks?

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.

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

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. :)

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

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.

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.

I just ran into a very similar situation where I had a library installed via

pip install -e ~/projects/mylibrary

and break points within that library would not work.  If I set breakpoints surrounding the problem packages I noticed that the stack also had frames marked with 'frame unavailable'.  I could step into those portions but it wouldn't show me where I was in the code.

I tried a few different things like clearing pycharm cache, reinstalling the library to no avail.  Once I finally thought to cleanup the compiled files (.pyc) in that package the debugger started working again.  At this point I sort of lost track of what happened but I suspect I ran that particular package in 3.8 at some point and then again in 3.7 (which is where I was seeing the problem)

Between your comments and what I was seeing I suspect there are enough differences between 3.7 and 3.8 to cause pycharm not to be able to debug all frames properly.  I'll have to do some reading up on .pyc files; I always assumed the interpreter was smart enough to realize the .pyc files from one version of python would not suffice and require a recompile when using another version. 🤷‍♂️

Run into the same problem. Cleanup all “.pyc” files  solved the issue for me