Basic Info
Environment: Windows 11
Python Version: 3.8.10
Use virtual env: Yes
VSCode Python extension version: v2022.20.2
Problem
I tried running an Odoo 15 (multi-threaded) application and previously I was able to see that VSCode properly tracked all spawned thread.
However yesterday when I tried to debug my application, I noticed that my breakpoints on code that was supposed to be run on spawned threads weren't hitting (main thread is fine).
After looking at the call stack window, I noticed that what used to be a list of threads are now showing nothing as if there's only 1 thread running.
Figure 1. Call stack on my Odoo program
So I'm wondering that it has something to do with my VSCode settings, but I'm drawing a blank on which. Interestingly, on my colleague's Linux machine, he can debug and see all the threads fine with VSCode
I've tried to do a clean uninstallation of VSCode and re-installed all extensions manually, but to no avail.
Interestingly, I tried writing a simple threaded program (with threading lib, same as Odoo's) and the call stack showed the multiple threads fine, so I'm lost as of why
Figure 2. Call stack on my simple threaded programs
Turns out I have an entry in my .env GEVENT_SUPPORT=True.
Once I erased that flag, everything works normal
Related
What to do when the python debugger seems to get stuck after running the first few (five) lines of code?
I have been using Python for quite a while, but starting yesterday, I have not been able to use the debugger. Whenever i try to run the debugger, it just displays the first 5 lines of the script and then stops.
If I then try to exit out of the debugger, it just displayer --KeyboardInterrupt-- but it does not terminate the process.
I am running Python 3.9 with Spyder, and have tried fixing it by restarting, resetting to factory setting, installing into a new environment, as well as a total uninstall and clear, and then installing from scratch, but nothing seems to work.
Even when i try running really basic scripts (like the images below) the result is the same
Running basic scripts normally (F5) works fine
But debugging just gets stuck
And terminating the debugger process is not possible
I am a Windows 10 user, and had configured the Python 3.10 IDLE to dark mode and had added the Fira Code font to the IDLE a few days back (Through the Options menu). Then the Python IDLE was working fine; without issues.
However, each time after that when I try to go to 'Configure IDLE' from Options Menu, Python IDLE just freezes and then stops responding, until I manually close it. It then asks to run a Windows check and reports the error to Windows. I have tried uninstalling and reinstalling Python; however that did not work.
Image: Python has stopped responding (happens everytime I click on configure IDLE)
I am a Windows user and tried running python from cmd using the command: py -m idlelib to start IDLE from the command line to try and get an error report, however the same problem happens as mentioned above, and I do not get an error report when I close Python. I tried finding solutions in similar questions, however I did not understand what was going on. I also do not seem to figure out how 'running the Python IDLE' through the command line works, other than running it using the above command. Can someone please assist me on what to do next at this point, that would be of huge help :D
Try uninstalling the font. The Doesn't work part of the Editor compatibility list on https://github.com/tonsky/FiraCode includes IDLE. I suspect that the font is incompatible with tcl/tk. Your report is similar to
IDLE Settings window won't appear
See https://bugs.python.org/issue45103 for so far futile efforts to protect IDLE.
UPDATE: We were not able to reproduce the problem with FireCode. However, the BPO issue referenced above lead to a tcl/tk bug report that lead to a bugfix, at least for the Phaistos font, that is included in tcl/tk 8.6.12. This is included in the new Python 3.9.9 Windows installer and will be in the upcoming 3.10.1 installer. It might fix your issue with FiraCode.
I recently started using Python. I realized that even the simplest program starts a Python process that never ends and causes my computer to overheat if I don't manually kill that process.
I've even seen multiple Python processes running at the same time after running a few easy Python programs (Hello, World!) in a row.
I updated to the latest Python version (Python 3.9.3), installed all the Certificates, and tested a few different programs to see if it happens every time—it does. I am using VSC as the IDE but the same situation happens even if I use IDLE.
My questions are: Is this an interpreter issue or a Mac issue? Can it be fixed?
Thank you very much.
I'm using Linux Eclipse (pydev) as IDE to develop python scripts that are launched by an application written in C++. I can debug the python script without problems in the IDE, but the environment is not real (the C++ program sends and receives messages through the stdin/stdout and it's a complex communication channel that I can't fully reproduce writing the messages by hand).
Until now I was using log messages to debug (poor man's debug) but it's getting too complex. When I do something similar in PHP I can just leave xdebug listening and add breakpoints in Netbeans. Very neat and easy. Is it possible to do something like that in Python 3.X (with Eclipse or other IDE)?
NOTE: I know there is a Pydev / Attach to Process functionality, but it doesn't work. Always fails to attach.
NOTE2: There is also a built-in "breakpoint()" in Python 3.7 but it links to a debugger and if also fails, the IDE never gets the control.
After some research, this is the best option I have found. Without any other solution provided, I post it just in case anyone has the same problem.
Python has an integrated debugger: pdb. It works as a module and it doesn't allow to use it if you don't have the window control (i.e. you launch the script).
To solve this there are some coders that have created modules that add a layer on pdb. I have tried some and the most easy and still visual interesting is rpudb (but have a look also to this).
To install it:
pip3 install https://github.com/msbrogli/rpudb/archive/master.zip
(if you install it using the pip3 install rpudb command it will install an old version only valid for python 2)
Then, you use it just adding an import and a function call:
import rpudb
.....
rpudb.set_trace('127.0.0.1', 4444)
.....
Launch the program and it will stop in the set_trace call. To debug it (and continue) open a terminal and launch a telnet like this:
telnet 127.0.0.1 4444
You will have a visual debugger in front of you with the advantage that you can not only debug local programs, but also remote (just change the IP).
I was able to attach PyCharm to a running python process and use break points using PyCharm attach to process
I created a bash script which exec a python script, should work the same with C++
I am trying to debug some c++ codes called from a python program (through python-c++ binding). My original approach was to start ipython, open lldb and attach the ipython process in lldb. Then go to ipython to run my python program. This works fine.
Now I want to take advantages of CLion IDE by attaching the ipython process inside CLion. However, When I did the attach process from CLion, it seems to attach to the process to the pydev debugger like below instead of attach the process to lldb:
Attaching to a process with PID=18016
/Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python /Applications/CLion.app/Contents/plugins/python/helpers/pydev/pydevd_attach_to_process/attach_pydevd.py --port 51406 --pid 18016
Connected to pydev debugger (build 183.5429.37)
However, I want the process to be attached to lldb, not pydev_debugger.
How do I force the attach_process in CLion to attach the process to lldb instead of pydev_debugger? Thanks!
There must be two entries in the attach dialog corresponding to the target process in question: attach using the pydev debugger and the native debugger. You may try filtering the list by the process PID in order to check that.
Please find a similar report in the CLion issue tracker here:
Inside the "Attach to Local Process..." dialog there're two kinds of processes you're able to attach to: one comes from CLion (attach with LLDB or GDB), another is provided by the Python plugin (attach with Python Debugger). Since the process you intend to attach to is a Python interpreter, the latter (the Python debugger) is suggested by default, while you should rather use the former (the CLion debugger) for debugging C/C++ code.