So I'm debugging my python program and have encountered a bug that makes the program hang, as if in an infinite loop. Now, I had a problem with an infinite loop before, but when it hung up I could kill the program and python spat out a helpful exception that told me where the program terminated when I sent it the kill command. Now, however, when the program hangs up and I ctrl-c it, it does not abort but continues running. Is there any tool I can use to locate the hang up? I'm new to profiling but from what I know a profiler can only provide you with information about a program that has successfully completed. Or can you use a profiler to debug such hang ups?
Haven't used it myself but I've heard that the Eric IDE is good and has a good debugger. That's also the only IDE I know of that has a debugger for Python
Nothing like the good old pdb
import pdb
pdb.run('my_method()',globals(),locals())
Then just hit (n) to go to the next command, (s) to step into. see the docs for the full reference. Follow your program step by step, and you'll probably figure it out fast enough.
It's easier to prevent these hang-ups than it is to debug them.
First: for
loops are very, very hard to get stuck in a situation where the loop won't terminate. Very hard.
Second: while
loops are relatively easy to get stuck in a loop.
The first pass is to check every while
loop to see if it must be a while
loop. Often you can replace while
constructs with for
, and you'll correct your problem by rethinking your loop.
If you cannot replace a while
loop with for
, then you simply have to prove that the expression in the while
statement must change every time through the loop. This isn't that hard to prove.
Look at all the condition in the loop. Call this T.
Look at all the logic branches in the body of the loop. Is there any way to get through the loop without making a change to the condition, T?
Yes? That's your bug. That logic path is wrong.
No? Excellent, that loop must terminate.
If your program has more than one thread, it could be ignoring ctrl-c because the one thread is wired up to the ctrl-c handler, but the live (runaway?) thread is deaf to it. The GIL (global interpreter lock) in CPython means that normally only one thread can actually be running at any one time. I think I solved my (perhaps) similar problem using this
Let's assume that you are running your program as:
python YOURSCRIPT.py
Try running your program as:
python -m trace --trace YOURSCRIPT.py
And have some patience while lots of stuff is printed on the screen. If you have an infinite loop, it will go on for-ever (halting problem). If it gets stuck somewhere, then mostly you are stuck on I/O or it is a deadlock.
Wow! 5 answers already and nobody has suggested the most obvious and simple:
- Try to find a reproducible test case that causes the hanging behavior.
- Add logging to your code. This can be as basic as "print **010", "print **020", etc. peppered through major areas.
- Run code. See where it hangs. Can't understand why? Add more logging. (I.e. if between **020 and **030, go and add **023, **025, **027, etc.)
- Goto 3.
Kids these days with their fancy debuggers & IDEs... Sometimes engineering problems are solved most simply with crude tools that provide just a little bit more information.
If your program is too big and complex to be viable for single stepping with pdb or printing every line with the trace module then you could try a trick from my days of 8-bit games programming. From Python 2.5 onwards pdb has the ability to associate code with a breakpoint by using the commands
command. You can use this to print a message and continue running:
(Pdb) commands 1
(com) print "*** Breakpoint 1 ***"
(com) continue
(com) end
(Pdb)
This will print a message and carry on running when breakpoint 1 is hit. Define similar commands for a few other breakpoints.
You can use this to do a kind of binary search of your code. Attach breakpoints at key places in the code and run it until it hangs. You can tell from the last message which was the last breakpoint it hit. You can then move the other breakpoints and re-run to narrow down the place in the code where it hangs. Rinse and repeat.
Incidentally on the 8-bit micros (Commodore 64, Spectrum etc) you could poke a value into a registry location to change the colour of the border round the screen. I used to set up a few breakpoints to do this with different colours, so when the program ran it would give a psychedelic rainbow display until it hung, then the border would change to a single colour that told you what the last breakpoint was. You could also get a good feel for the relative performance of different sections of code by the amount of each colour in the rainbow. Sometimes I miss that simplicity in these new fangled "Windows" machines.
Wow ! Seems you added so much code in one go without testing it that you can't say what code was added just before program started to hang... (the most likely cause of problem).
Seriously, you should code by small steps and test each one individually (ideally doing TDD).
For your exact problem of spotting what python code is running and ctrl-c does not work, I will try a raw guess: did you used some except:
catching all exceptions indistinctly. If you did so in a loop, it's a very likely reason why ctrl-c does not work : it's catched by this exception. Change to except Exception:
and it should not be catched any more (there is other possibilities for ctrl+c not working like thread management as another poster suggested, but I believe the above reason is more likely).