I'm relatively new to python and pdb, but I have a lot of experience with gdb.
My problem is that if I set a number of breakpoints in my code at some point I will want to change something and re-run my debug session retaining these break points. However entering "run" in my pdb session cases my session to terminate with the following output
(Pdb) run
Traceback (most recent call last):
File "/usr/lib64/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/lib64/python2.6/pdb.py", line 1319, in <module>
pdb.main()
File "/usr/lib64/python2.6/pdb.py", line 1312, in main
pdb.interaction(None, t)
File "/usr/lib64/python2.6/pdb.py", line 198, in interaction
self.cmdloop()
File "/usr/lib64/python2.6/cmd.py", line 142, in cmdloop
stop = self.onecmd(line)
File "/usr/lib64/python2.6/pdb.py", line 267, in onecmd
return cmd.Cmd.onecmd(self, line)
File "/usr/lib64/python2.6/cmd.py", line 219, in onecmd
return func(arg)
File "/usr/lib64/python2.6/pdb.py", line 661, in do_run
raise Restart
pdb.Restart
]$
I've tried this on two independent linux platforms and had the same result but I cannot find any corrections in the documentation.
So if anyone cares the problem was that "run" in pdb is not the exact same as "run" in gdb. In gdb if I enter run the program restarts and continues to the first break point. In pdb the program restarts and goes to the start of the file. I then have to press 'n' followed by 'c' to get to the first break point. If, attempting to get the program to run, I type run a second time at the start of the file the debugger crashes, as shown above.
Here is my file test.py:
import pdb
pdb.set_trace()
print('1 line')
I get the same error when I using command 'python3 test.py':
> /home/wangpq/program_note/test.py(3)<module>()
-> print('1 line')
(Pdb) run
Traceback (most recent call last):
File "program_note/test.py", line 3, in <module>
print('1 line')
File "program_note/test.py", line 3, in <module>
print('1 line')
File "/usr/lib/python3.5/bdb.py", line 48, in trace_dispatch
return self.dispatch_line(frame)
File "/usr/lib/python3.5/bdb.py", line 66, in dispatch_line
self.user_line(frame)
File "/usr/lib/python3.5/pdb.py", line 259, in user_line
self.interaction(frame, None)
File "/usr/lib/python3.5/pdb.py", line 346, in interaction
self._cmdloop()
File "/usr/lib/python3.5/pdb.py", line 319, in _cmdloop
self.cmdloop()
File "/usr/lib/python3.5/cmd.py", line 138, in cmdloop
stop = self.onecmd(line)
File "/usr/lib/python3.5/pdb.py", line 412, in onecmd
return cmd.Cmd.onecmd(self, line)
File "/usr/lib/python3.5/cmd.py", line 217, in onecmd
return func(arg)
File "/usr/lib/python3.5/pdb.py", line 1022, in do_run
raise Restart
pdb.Restart
Then I use command 'python3 -m pdb test.py'
wangpq#wangpq:~$ python3 -m pdb program_note/test.py
> /home/wangpq/program_note/test.py(1)<module>()
-> import pdb
(Pdb) restart
Restarting program_note/test.py with arguments:
program_note/test.py
> /home/wangpq/program_note/test.py(1)<module>()
-> import pdb
(Pdb)
It works. So far, I am not sure why this happens.
Upon encountering an abnormal condition (i.e., a bug in your program), pdb rather helpfully says:
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
Here, typing "run" or "restart" will cause the pdb process to unceremoniously terminate as OP states (but "cont" or "step" will restart as promised).
Presumably many impatient pythonistas would rather "run" or "restart" work regardless of whether we've entered "post mortem debugging" but I'm sure the existing restart semantics is the byproduct of a cleaner implementation.
Related
When I use the VS Code debugger with Python to stop at some breakpoints, I often write some lines straight in the debug console (use it as interactive Python shell within my program).
The problem is, when I have errors in these lines, when typed from the debug console, I don't see the full Python-style traceback of the error, but only the last line (<Error_type>: ), i.e., without references to code file where the error was raised, the line raised it, and the full stack trace.
Is there any way to configure the VS Code debugger to show the full traceback for errors raised by lines executed from the debugger?
I develop (and debug) on remote machine through ssh.
Example:
I wrote a file named tmp2.py, which contains:
class A:
def __init__(self, val):
print(val)
a = A()
If I put debug point on line 5: print('start'),
and then from the debug console type directly a = A(), I see this one line output:
TypeError: __init__() missing 1 required positional argument: 'val'
but if I run the full program I see the this elaborated output:
Traceback (most recent call last):
File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/__main__.py", line 45, in <module>
cli.main()
File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/../debugpy/server/cli.py", line 430, in main
run()
File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/../debugpy/server/cli.py", line 267, in run_file
runpy.run_path(options.target, run_name=compat.force_str("__main__"))
File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 263, in run_path
pkg_name=pkg_name, script_name=fname)
File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 96, in _run_module_code
mod_name, mod_spec, pkg_name, script_name)
File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/innereye/deeplearning/tmp2.py", line 6, in <module>
a = A()
TypeError: __init__() missing 1 required positional argument: 'val'
which directs me to the actual file and line where the error raises.
I want the debugger to show me the second output also for lines executed directly from the debug console.
Sorry, but it seems like impossibleļ¼ VSCode hasn't provided related configuration. And I consider that's very hard to get what you want, this is because of the debug theory.
I suddenly cannot set any breakpoint in my python program. Note there are two (Pdb) showing up. I wonder if the Pdb was damaged before. I did try to step into some compiled C++ code in an abc.so file using Pdb before this issue started happening:
-> print('haha')
(Pdb) (Pdb)
Traceback (most recent call last):
File "high.py", line 38, in <module>
print('haha')
File "high.py", line 38, in <module>
print('haha')
File "/Users/ludaming/anaconda2/lib/python2.7/bdb.py", line 49, in trace_dispatch
return self.dispatch_line(frame)
File "/Users/ludaming/anaconda2/lib/python2.7/bdb.py", line 68, in dispatch_line
if self.quitting: raise BdbQuit
bdb.BdbQuit
Now I figured it out that the Pdb is not malfunctioning. It is because Python reads from stdin right next to the Pdb, which enters to the Pdb's interactive console and causing a problem. So a bypass is to read from file instead of stdin
fp = open(sys.argv[1], 'r')
t = int(fp.readline())
instead of
t = int(raw_input())
I am developing a package that uses unittest for its tests. The tests are all in a submodule called tests. At the bottom of the submodule is this:
if __name__ == '__main__':
unittest.main()
But if you run the module, Windows closes the command window before one can read the output. OK, this is not a new problem. There are ways around this, for example making a shortcut that looks something like:
cmd /k "python -m mypackage.tests"
This works, now you get to see the output. But then you are dumped back at the C:\Windows\System32 command prompt. It would be nicer to be able to still be in the Python interpreter, so that I can play around in Python if something occurs to me to check after I saw the tests. So you try something like this:
cmd /k "python -i -m mypackage.tests"
But, whoa, what's this? after the test output, you see
Traceback (most recent call last):
File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\Python33\lib\runpy.py", line 73, in _run_code
exec(code, run_globals)
File "D:\Docs\programs\python\mypackage\tests.py", line 274, in <module>
unittest.main()
File "C:\Python33\lib\unittest\main.py", line 125, in __init__
self.runTests()
File "C:\Python33\lib\unittest\main.py", line 267, in runTests
sys.exit(not self.result.wasSuccessful())
SystemExit: True
>>>
You are still in the Python interpreter, but now for some reason there are several lines of dumb noise in between the test results and the new prompt. No-one wants to see that. It is presumably because unittest.main() tries to exit the interpreter but the interpreter doesn't let it happen because you used the -i option. Which is good in a way, but the traceback isn't wanted.
You look at the documentation for unittest to see if there is a way to make Python stick around after running the tests. There are no command line switches for unittest that have this effect, but there is a keyword argument exit that could be used to prevent unittest from trying to close Python. So we could change the end of tests.py to this:
if __name__ == '__main__':
unittest.main(exit = False)
The problem with this is that sometimes you might want the default behaviour of closing the interpreter, like say if you had your version control software run the tests module automatically. So it would be best to have some way of conditionally disabling the exit. Well, it seems like by implementing a rudimentary check for command line options this could be done. So we try changing it to
if __name__ == '__main__':
import sys
unittest.main(exit = 'noexit' not in ''.join(sys.argv[1:]))
and the shortcut to
cmd /k "python -i -m mypackage.tests --noexit"
But now when you run it the tests don't even run, instead you see a big wall of complaints about how there's no option called "noexit":
Usage: tests.py [options]
tests.py: error: no such option: --noexit
Traceback (most recent call last):
File "C:\Python33\lib\optparse.py", line 1391, in parse_args
stop = self._process_args(largs, rargs, values)
File "C:\Python33\lib\optparse.py", line 1431, in _process_args
self._process_long_opt(rargs, values)
File "C:\Python33\lib\optparse.py", line 1484, in _process_long_opt
opt = self._match_long_opt(opt)
File "C:\Python33\lib\optparse.py", line 1469, in _match_long_opt
return _match_abbrev(opt, self._long_opt)
File "C:\Python33\lib\optparse.py", line 1674, in _match_abbrev
raise BadOptionError(s)
optparse.BadOptionError: no such option: --noexit
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\Python33\lib\runpy.py", line 73, in _run_code
exec(code, run_globals)
File "D:\Docs\programs\python\mypackage\tests.py", line 275, in <module>
unittest.main(exit = 'noexit' not in ''.join(sys.argv[1:]))
File "C:\Python33\lib\unittest\main.py", line 124, in __init__
self.parseArgs(argv)
File "C:\Python33\lib\unittest\main.py", line 148, in parseArgs
options, args = parser.parse_args(argv[1:])
File "C:\Python33\lib\optparse.py", line 1393, in parse_args
self.error(str(err))
File "C:\Python33\lib\optparse.py", line 1573, in error
self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
File "C:\Python33\lib\optparse.py", line 1563, in exit
sys.exit(status)
SystemExit: 2
Well I think I should be the one who decides what command line options there are, but maybe I haven't gone through the correct formalities to declare what command line options I'll accept. But actually, no, that isn't the case, because if I comment out the line that calls unittest.main():
if __name__ == '__main__':
import sys
#unittest.main(exit = 'noexit' not in ''.join(sys.argv[1:]))
then there is no complaining at all, just a >>> prompt! From which I can only deduce that unittest.main() is for some reason inspecting the command line arguments to my script, and throwing a hissy fit when they don't meet its standards - this despite the fact that they aren't directed at it in the first place. This wouldn't be so much of a problem if there were a command line switch that made it hang around instead of exiting (like the exit keyword argument does), but there isn't.
What's the answer? Every option seems unsatisfactory in one way or another.
I have parent process calling its child. I've put import pdb; pdb.set_trace() into the child process code.
When I launch the parent with python -m pdb parent.py it's getting frozen. The debugger doesn't respond to any command I type. But when I hit quit or continue it does exits code.
It looks like pdb works, but doesn't produce any output.
$ python -m pdb parent.py
n -m pdb parent.py
> d:\scripts\parent.py(53)<module>()
-> '''
(Pdb) c
It stops responding now.
According to the trace I get after interruption, it was standing at the line just after the pdb.set_trace() call.
>>>>>>>>>>>>>[2013.06.13-10:02:06] : accessed by child.py
Traceback (most recent call last):
File "child.py", line 40, in <module>
sys.stderr = open(Definition_h.ErrLog, 'a', 0, encoding=Definition_h.utf8)
File "d:\scripts\Definition_h.py", line 863, in unicodeOpen
def unicodeOpen(*args, **kwargs):
File "C:\Program Files (x86)\Python 2.5.4\lib\bdb.py", line 50, in trace_dispatch
return self.dispatch_call(frame, arg)
File "C:\Program Files (x86)\Python 2.5.4\lib\bdb.py", line 79, in dispatch_call
self.user_call(frame, arg)
File "C:\Program Files (x86)\Python 2.5.4\lib\pdb.py", line 134, in user_call
self.interaction(frame, None)
File "C:\Program Files (x86)\Python 2.5.4\lib\pdb.py", line 187, in interaction
self.cmdloop()
File "C:\Program Files (x86)\Python 2.5.4\lib\cmd.py", line 148, in cmdloop
import readline
KeyboardInterrupt: !!!<unprintable KeyboardInterrupt object>
Error in sys.excepthook:
Actually the problem was that my code was redirecting sys.stdout to the log file
My mistake was that the script was launched in background mode with the ampersand & at the end.
So I got the pdb prompt but no command would execute.
I'm having trouble running tasks. I run ./manage celeryd -B -l info, it correctly loads all tasks to registry.
The error happens when any of the tasks run - the task starts, does its thing, and then I get:
[ERROR/MainProcess] Thread 'ResultHandler' crashed: ValueError('Octet out of range 0..2**64-1',)
Traceback (most recent call last):
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/concurrency/processes/pool.py", line 221, in run
return self.body()
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/concurrency/processes/pool.py", line 458, in body
on_state_change(task)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/concurrency/processes/pool.py", line 436, in on_state_change
state_handlers[state](*args)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/concurrency/processes/pool.py", line 413, in on_ack
cache[job]._ack(i, time_accepted, pid)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/concurrency/processes/pool.py", line 1016, in _ack
self._accept_callback(pid, time_accepted)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/worker/job.py", line 424, in on_accepted
self.acknowledge()
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/worker/job.py", line 516, in acknowledge
self.on_ack()
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/celery/worker/consumer.py", line 405, in ack
message.ack()
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/kombu-2.1.0-py2.7.egg/kombu/transport/base.py", line 98, in ack
self.channel.basic_ack(self.delivery_tag)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/amqplib-1.0.2-py2.7.egg/amqplib/client_0_8/channel.py", line 1740, in basic_ack
args.write_longlong(delivery_tag)
File "/Users/jzelez/Sites/my_virtual_env/lib/python2.7/site-packages/amqplib-1.0.2-py2.7.egg/amqplib/client_0_8/serialization.py", line 325, in write_longlong
raise ValueError('Octet out of range 0..2**64-1')
ValueError: Octet out of range 0..2**64-1
I also must note that this worked on my previous Lion install, and even if I create a blank virtualenv with some test code, when a task runs it gives this error.
This happens with Python 2.7.2 and 2.6.4.
Django==1.3.1
amqplib==1.0.2
celery==2.4.6
django-celery==2.4.2
It appears there is some bug with homebrew install python. I've now switched to the native Lion one (2.7.1) and it works.