I have code contains many files and many functions.
In Pycharm 2019 IDE, the debugger stop on breakpoints in most of the files correctly, but in some files, the debugger crossed the breakpoints and absolutely deny it.
It should be noted that I checked the running details and I added some print lines near breakpoints and I can see my prints in the console.
In these files, The debugger runs the code instead of debugging!!!
How can I solve this problem?
This could happen for many reasons and impossible to state a direct answer. It's also hard to identify the problem without the relevant code.
Here are some possibilities.
An unhandled exception was raised by code long before we ever got to the code containing a breakpoint. That is, the code which gets executed before the code containing a break-point contains an error.
The code containing a break-point is never executed, even when the script runs from start to finish. For example, if the break-point is inside an if-block and the condition of the if-statement is never true, then the breakpoint will never be reached.
You are not running the script you think you are running. Look in the upper right corner of the UI. What is the name of the file next to the run button (green triangle)?
Check that thr suspend options are ticked in. Follow these steps: Go to Run->View breakpoints and check if the Suspend option is
ticked in.
Related
Google'd but only getting results about how we can create launch.json configs and start the debugging from line #1.
So I have a [big?] Python project that runs from command-line, and I just created a helper method (def pauseHereAndNotifyUserOnSlack(user=<username>) to pause where needed and wait for the user to press a key to exit out of this [infinite] loop and resume the code.
I am wondering if there's a way to attach my python project while the code is paused, inspect the variables and stuff, and resume execution from there?
(Think C#/C++ has this feature, where they attach using symbols and stuff? Not 100% sure how this works. Maybe I am confusing myself?)
Let me know if you guys need more clarification. TIA
You don't need to debug your code from line 1, set breakpoints in your code and start debugging from there and inspect variables and can also resume execution from there. (if this is what you were talking about)
the play button can be used to resume your execution.
The main Python code calls my written functions that for better overview are stored in separate .py files. For improvement of my code the program shall start from the beginning and stop at a defined position where I want to do some repair. After stopping I want to have access to the local variables where the code has stopped. This means I want to select some code that was performed before the halt and manipulate this code in the console. After testing in the console I want to correct my original code and run again the program.
Example:
You suppose that the following line doesn't execute as you expect:
if a.find('xyz')==-1:
Therefore you stop the program just before:
breakpoint()
if a.find('xyz')==-1:
Now you want to find out why exactly the line is not working as you expected. Maybe it depends on the variable a or on the string xyz or the find command is not correctly applied? So I would now enter a.find('xyz') in the console, vary and adjust the command. After a few tests in the console I find out that the right command must be a.find('XYZ'). Now I correct the line in my original code and restart the program. ---
But this is not possible because the halt command breakpoint() or pdb.set_trace() prohibits me from using the console. Instead I end up in debug mode where I can only run through the code line by line or display variables.
How can I debug my code as desired?
The following workarounds also do not help:
sys.exit()
I stop the code with sys.exit(). Main problem with this method is that I have no access to the variables if the code has stopped in another file. Also I do not see where the program has stopped. If I have several sys.exit() instances distributed in large code I do not know at which instance it has stopped. I can define individual outputs by sys.exit(‘position1’), sys.exit(‘position2’), but still I have to manually find the file and scroll to the given position.
cells
I define cells with #%%. Then I can run these cells separately, but I cannot run all cells from the beginning until the end of a given cell.
Spyder 5.2.2
I have a created a python to get input files from windows folder and updated the excel sheet every 15 minutes. Program is always open - running in background.
Program was running properly for 2 weeks and suddenly the program closed with error message 'A problem caused the program stop working correctly and was closed". I have checked the log files and didn't see any error message.
I checked the Windows log viewer and error was present with below text, which i could not interpret properly. Can anyone please let me the possible causes for the error.
Program.exe
0.0.0.0
5a2e9e81
python36.dll
3.6.5150.1013
5abd3161
c00000fd
0000000000041476
1ba8
01d45e9fe43cba57
C:\Python code\program.exe
C:\Users\aisteam\AppData\Local\Temp\2_MEI51602\python36.dll
a9da018c-e2e3-4821-9387-cce82ff29186
Make sure that your python code robustly handles errors like when the file it wants to update is locked, which is what Excel does while the file is open in Excel. by design, you could easily make your code create a new excel file each time, or wait until the file isn’t locked then update it. Either way, you need to make your code better at telling you what it is doing, e.g. by logging what it is doing (which is important to implement now because the logging needs to be in place before your code stops unexpectedly for, err, an unexpected reason), e.g. by carefully managing exceptions (i.e. don’t simply code as try/except:pass!)
BUT don’t do this sort of code with an unconditional except and nothing but a pass in the except: statement) because it will make errors HARDER to figure out:
try:
something
except:
pass
Always be specific about the exception you expect, and even if you are going to not raise, always always always log the exception.
While debugging my Python 3.5 pogram in Pycharm 5.0.4, I am trying to hit the pause button to find how why/where the program is hanging (as can be done in Visual Studio).
However, nothing happens: the pause button does not become grey and the resume button stays grey, and in the debugger tool window, "Frames are not available".
I tried with different basic programs, on Linux and on Windows, to no avail.
Is this a bug or am I missing something in how Pycharm debugging is supposed to work?
I also noticed that when a breakpoint is hit, only one thread is suspended and I could see no way to suspend other threads to inspect their stack frames. I would be interested to know how to achieve this thread-specific suspension as well.
Sounds like your program is hanging on a sleep or something of that sort, or maybe on some native code.
If it was a regular python loop the pause python would work.
I believe the problem is with python itself and not the debug tool you are using.
When you pause a python program you pause the interperter and so all threads that are running in the context of the interperter are paused and you can see the them in the frames window. Any thread that show the message "Frames not available in non-suspended state" is not suspended because it is was sleeping when you paused the program.
see this for how to debug c code
Not working python breakpoints in C thread in pycharm or eclipse+pydev
Within PyCharm, there is an option for debugging, that will allow you to step through your code, which may be of more use, rather than trying to pause the program.
You need to insert a break point in the code initially; just click in the grey bar at the line you want to break at:
Then you can press Alt+Shift+F9, or click Run > Debug in the menu to start stepping through the code from that point:
Once you have started the debug mode, click the button highlighted by the red circle - this will enable you to step through the code, looking at the variables, their assignments and if you receive any errors.
If you need to stop at any point, just hit the red Stop button on the left of the debug window.
The console tab will allow you to see what is being printed to the screen (if anything), and at what point, save you having loads of print statements like you would if debugging using Idle or similar IDEs
HTH
A fairly large Python program I write, runs, but sometimes, after running for minutes or hours, in a non easily reproducible moment, hangs and outputs nothing to the screen.
I have no idea what it is doing at that moment, and in what part of code it is.
How can I run this in a debugger or something to see what lines of code is the program executing in the moment it hangs?
Its too large to put "print" statements all over the place.
I did:
python -m trace --trace /usr/local/bin/my_program.py
but that gives me so much output that I can't really see anything, just millions of lines scrolling on the screen.
Best would be if I could send some signal to the program with "kill -SIGUSR1" or something, and at that moment the program would drop into a debugger and show me the line it stopped at and possibly allow me to step through the program then.
I've tried:
pdb usr/local/bin/my_program.py
and then:
(Pdb) cont
but what do I do to see where I am when it hangs?
It doesn't throw and exception, just seems like it waits for something, possibly in an infinite loop.
One more detail: when the program hangs, and I press ^C and then (not sure if that is necessary) the program continues normally (without throwing any exception and without giving me any hint on the screen why did it stop).
This could be useful to you. I usually do
>>> import pdb
>>> import program2debug
>>> pdb.run('program2debug.test()')
I usually add a -v option to my programs, which enables tons of print statements explaining what I'm doing in detail. When you write a program in the future, consider doing the same before it gets thousands of lines big.
You could try running it in debug mode in an IDE like pydev (eclipse) or pycharm. You can break the program at any moment and get to its current execution point.
No program is ever too big to put print statements all over the place. You need to read up on the logging module and insert lots of logging.debug() statements. This is just a better form of print statement that outputs to a file, and can be turned off easily in production software. But years from now, when you need to modify the code, you can easily turn it all back on and get the benefit of the insight of the original programmer.