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.
Related
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'm having problems with attaching to gevent-based processes with the PyDev's debugger under PyDev 3.9.2.
It works fine in PyDev 3.9.1 and LiClipse 3.9.1, just not with 3.9.2 which is the latest PyDev right now (6 Feb, 2015).
It also works properly when a piece of code is run directly from PyDev's debugger rather than externally.
Note that it doesn't depend on whether there are breakpoints set (enabled or not) - the mere fact of attaching to a process suffices for the exception to be raised.
Here is a sample module to reproduce the behaviour along with two exceptions - one from PyDev and the other one from the gevent code's point of view.
Can anyone please shed any light on it? Thanks a lot.
from gevent.monkey import patch_all
patch_all()
import threading
import gevent
def myfunc():
t = threading.current_thread()
print(t.name)
while True:
gevent.spawn(myfunc)
gevent.sleep(1)
Debug Server at port: 5678
Traceback (most recent call last):
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd_attach_to_process/attach_script.py", line 16, in attach
patch_multiprocessing=False,
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 1828, in settrace
patch_multiprocessing,
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 1920, in _locked_settrace
CheckOutputThread(debugger).start()
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 261, in start
thread.start()
File "/usr/lib/python2.7/threading.py", line 750, in start
self.__started.wait()
File "/usr/lib/python2.7/threading.py", line 620, in wait
self.__cond.wait(timeout)
File "/usr/lib/python2.7/threading.py", line 339, in wait
waiter.acquire()
File "_semaphore.pyx",...
Traceback (most recent call last):
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd_attach_to_process/attach_script.py", line 16, in attach
patch_multiprocessing=False,
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 1828, in settrace
patch_multiprocessing,
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 1920, in _locked_settrace
CheckOutputThread(debugger).start()
File "/opt/slow/01/data/install/pydev/eclipse/plugins/org.python.pydev_3.9.2.201502050007/pysrc/pydevd.py", line 261, in start
thread.start()
File "/usr/lib/python2.7/threading.py", line 750, in start
self.__started.wait()
File "/usr/lib/python2.7/threading.py", line 620, in wait
self.__cond.wait(timeout)
File "/usr/lib/python2.7/threading.py", line 339, in wait
waiter.acquire()
File "_semaphore.pyx", line 112, in gevent._semaphore.Semaphore.acquire (gevent/gevent._semaphore.c:3004)
File "/home/dsuch/projects/pydev-plugin/pydev-plugin/local/lib/python2.7/site-packages/gevent/hub.py", line 330, in switch
switch_out()
File "/home/dsuch/projects/pydev-plugin/pydev-plugin/local/lib/python2.7/site-packages/gevent/hub.py", line 334, in switch_out
raise AssertionError('Impossible to call blocking function in the event loop callback')
AssertionError: Impossible to call blocking function in the event loop callback
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 am calling an R script file from python using pyrserve. I have rserve running. At arbitrary points in the R script, pyrserve gives an error and quits:
Traceback (most recent call last):
File "scriptV2.py", line 272, in <module>
rConn.eval("source(file.PropensityFlow)")
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rconn.py", line 47, in decoCheckIfClosed
return func(self, *args, **kw)
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rconn.py", line 119, in eval
return rparse(src, atomicArray=atomicArray)
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rparser.py", line 539, in rparse
return rparser.parse()
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rparser.py", line 349, in parse
self.lexer.readHeader()
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rparser.py", line 94, in readHeader
self.responseCode = struct.unpack(b'<i', self.read(3) + b'\x00')[0]
File "/Users/dipayanmaiti/Py3.3venv/lib/python3.3/site-packages/pyRserve/rparser.py", line 149, in read
raise EndOfDataError()
pyRserve.rparser.EndOfDataError
I have set rserv.conf to the following:
maxinbuf 20000000
maxsendbuf 0
Does anybody know why this happens? This looks like some buffer problem, because the R script runs by itself.
It is a late answer, but in such situations it is useful to run Rserve in debug mode so its output can be monitored in a separate shell.
R CMD Rserve.dbg
In some rare cases I've seen Rserve printing warnings to the console, and when this happened the command sent thru pyRserve didn't return any value from Rserve - which led to the 'EndOfDataError' above.
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.