3

I am getting a really strange output when running a python script and setting a break point with ipdb as in this program: 

import sys
import ipdb
parents, babies = (1, 1)
while babies < 100:
    ipdb.set_trace()
    print 'This generation has {0} babies'.format(babies)
    ipdb.set_trace()
    parents, babies = (babies, parents + babies)

It all works fine when running the script at first, stopping at the first break point and printing all the variables. But as soon as I approach the second break point where it doesn't matter if I step through it or just continue, I get these kind of weird characters as output in the console: 

C:\pythontest>python ipdb_test2.py
> c:\pythontest\ipdb_test2.py(6)<module>()
      5         ipdb.set_trace()
----> 6         print 'This generation has {0} babies'.format(babies)
      7         ipdb.set_trace()

ipdb> n
This generation has 1 babies
> c:\pythontest\ipdb_test2.py(7)<module>()
      6         print 'This generation has {0} babies'.format(babies)
----> 7         ipdb.set_trace()
      8         parents, babies = (babies, parents + babies)

ipdb> n
> ←[1;32mc:\pythontest\ipdb_test2.py←[0m(8)←[0;36m<module>←[1;34m()←[0m
←[1;32m      6 ←[1;33m        ←[1;32mprint←[0m ←[1;34m'This generation has {0} b
abies'←[0m←[1;33m.←[0m←[0mformat←[0m←[1;33m(←[0m←[0mbabies←[0m←[1;33m)←[0m←[1;33
m←[0m←[0m
←[0m←[1;32m      7 ←[1;33m        ←[0mipdb←[0m←[1;33m.←[0m←[0mset_trace←[0m←[1;3
3m(←[0m←[1;33m)←[0m←[1;33m←[0m←[0m
←[0m←[1;32m----> 8 ←[1;33m        ←[0mparents←[0m←[1;33m,←[0m ←[0mbabies←[0m ←[1
;33m=←[0m ←[1;33m(←[0m←[0mbabies←[0m←[1;33m,←[0m ←[0mparents←[0m ←[1;33m+←[0m ←[
0mbabies←[0m←[1;33m)←[0m←[1;33m←[0m←[0m
←[0m
ipdb> n
> ←[1;32mc:\pythontest\ipdb_test2.py←[0m(4)←[0;36m<module>←[1;34m()←[0m
←[1;32m      3 ←[1;33m←[0mparents←[0m←[1;33m,←[0m ←[0mbabies←[0m ←[1;33m=←[0m ←[
1;33m(←[0m←[1;36m1←[0m←[1;33m,←[0m ←[1;36m1←[0m←[1;33m)←[0m←[1;33m←[0m←[0m
←[0m←[1;32m----> 4 ←[1;33m←[1;32mwhile←[0m ←[0mbabies←[0m ←[1;33m<←[0m ←[1;36m10
0←[0m←[1;33m:←[0m←[1;33m←[0m←[0m
←[0m←[1;32m      5 ←[1;33m        ←[0mipdb←[0m←[1;33m.←[0m←[0mset_trace←[0m←[1;3
3m(←[0m←[1;33m)←[0m←[1;33m←[0m←[0m
←[0m
ipdb>

As soon as I hit the ipdb.set_trace() command the second time it will output these kind of characters and from that point on the debugger becomes unusable. I tried it on different consoles but the error seems to persist.

I am using Python 2.7.8 with Anaconda 2.1.0 (64 bit) on Windows, any ideas how to solve this problem are warmly welcomed.

aegger
  • 342
  • 1
  • 2
  • 13
  • is there any reason why you're using ipdb? pdb works fine for me. – zom-pro Aug 16 '15 at 18:00
  • True but ipdb was recommended to me by a friend to be more versatile. I also prefer the default coloring of ipdb than the plain black white output of pdb, also no intendation is done by pdb. It does work when calling "python -m ipdb ipdb_test2.py" and setting breakpoints interactively. I find this a bit cumbersome though – aegger Aug 17 '15 at 08:17

2 Answers2

5

The strange output are ANSI escape codes. That's how ipdb does syntax highlighting. However CMD windows don't support the escape codes by default, it's been that way since DOS days. You have to enable a special driver named ANSI.SYS for the control codes to work. ipdb must be pulling some kind of magic that breaks the second time you call set_trace().

Seth Sims
  • 66
  • 1
  • 3
  • Thanks a lot for your answer! However on [Wikipedia](https://en.wikipedia.org/wiki/ANSI.SYS#Occurrence) it says there is no ANSI.SYS file present starting from Windows 7 anymore. Also now on Windows 10 I do not experience this error anymore. I am not quite sure if that's only because of OS change, but I don't think I changed any other configurations. – aegger Dec 05 '16 at 22:29
  • Anyhow, your answer is helpful since the problem is about ANSI escape codes which are indeed supported now for the first time in a Win32 console in Windows 10 (according to your wikipedia link). In previous versions of Windows you would need to enable this driver manually. Thanks again :-) – aegger Dec 06 '16 at 22:33
-1

The normal approach for using ipdb (and pdb as far as I know) is to only set one import ipdb; ipdb.set_trace() command in your code where you want to break into the debugger. From there you can set other breakpoints, using the break or b command and then pressing continue or c to get to that breakpoint. Consider this simple pdb session for example:

➜  python  python hello.py
hello
> /Users/kermit/Dropbox/dev/skripte/python/hello.py(4)<module>()
-> print('hello 2')
(Pdb) l
  1     print('hello')
  2     import pdb; pdb.set_trace()
  3
  4  -> print('hello 2')
  5     print('hello 3')
[EOF]
(Pdb) b 5
Breakpoint 1 at /Users/kermit/Dropbox/dev/skripte/python/hello.py:5
(Pdb) c
hello 2
> /Users/kermit/Dropbox/dev/skripte/python/hello.py(5)<module>()
-> print('hello 3')
(Pdb)
metakermit
  • 21,267
  • 15
  • 86
  • 95
  • Ok that's possible of course. But what if I want to set a breakpoint in a loop and check the value of a variable in each iteration? Then when i insert the line `import ipdb; ipdb.set_trace()` within the loop I have the same problem, as I'm approaching the line the second time. I know the problem does not occur with pdb but I really prefer the output style of ipdb – aegger Aug 27 '15 at 19:34
  • so what I would do then would be to insert `import ipdb; ipdb.set_trace()` just before the loop, once inside the debugger use the `break` command to insert another breakpoint dynamically that is within the loop and then `continue` at will to inspect the state at every iteration. – metakermit Aug 27 '15 at 19:41
  • Ok that's a good workaround. I will continue using ipdb now like this, but still interested what actually causes this output, which seems to be ipdb specific. When I have more time I will dig into this problem further. – aegger Aug 27 '15 at 19:49