Tuesday, July 25, 2006
Week 9
Been working on allowing debugging by a debugger running in a separate process for most of this week. I pushed this forward in the list of things to do (in front of thread debugging) as I'd spent quite a long time working on allowing thread debugging and was getting a little frustrated. Ok,
so, 'debugging an already running process?', I hear you say. Yes! I'll give a quick overview, if you're interested, check out the documentation in the sandbox/pdb/Doc directory.
So, you've got your simple chat application, that allows clients to connect to a server and messages are broadcast to each of the clients. But you're a little unsure if the code you've written is totally stable, you'd better be able to debug it. But you realise you want to debug the program from a different terminal, but still on the same machine (think, logging in to a machine at work from home). Add this little bit of code to enable debugging from another process
What this does is sets up a signal handler and when it catches a signal a pdbserver is started. You can specify the pdbserver parameters by passing them to process_debugging. The default
connection parameters are a FIFO connection with a filename composed of the temp directory on your system (as returned by tempfile.gettempdir()), the PID of the process and the word 'mpdb'. For, for example, running this on my NetBSD machine I get,
But say, you wanted to start a pdbserver using TCP on localhost:8000 (you can only use localhost as a hostname for a TCP connection with process_debugging),
Now a debugger can start a debugging session by issuing the 'attach' command, which takes a PID as an argument and sends (by default) a SIGUSR1 signal to that PID. This gets handled by the handler in mpdb and starts a pdbserver. The debugger then connects. *BAM* have a debugging-good-time. By the way, use the 'detach' command to detach from the debugger, as it allows the program being debugged to continue execution. Typing 'quit' quits the program :P
so, 'debugging an already running process?', I hear you say. Yes! I'll give a quick overview, if you're interested, check out the documentation in the sandbox/pdb/Doc directory.
So, you've got your simple chat application, that allows clients to connect to a server and messages are broadcast to each of the clients. But you're a little unsure if the code you've written is totally stable, you'd better be able to debug it. But you realise you want to debug the program from a different terminal, but still on the same machine (think, logging in to a machine at work from home). Add this little bit of code to enable debugging from another process
import mpdb ; mpdb.process_debugging()
What this does is sets up a signal handler and when it catches a signal a pdbserver is started. You can specify the pdbserver parameters by passing them to process_debugging. The default
connection parameters are a FIFO connection with a filename composed of the temp directory on your system (as returned by tempfile.gettempdir()), the PID of the process and the word 'mpdb'. For, for example, running this on my NetBSD machine I get,
>>> import mpdb ; mpdb.process_debugging()
'mconnection.MConnectionServerFIFO /tmp/25813mpdb'
But say, you wanted to start a pdbserver using TCP on localhost:8000 (you can only use localhost as a hostname for a TCP connection with process_debugging),
>>> mpdb.process_debugging(protocol='tcp', addr=':8000')
'tcp :8000'
Now a debugger can start a debugging session by issuing the 'attach' command, which takes a PID as an argument and sends (by default) a SIGUSR1 signal to that PID. This gets handled by the handler in mpdb and starts a pdbserver. The debugger then connects. *BAM* have a debugging-good-time. By the way, use the 'detach' command to detach from the debugger, as it allows the program being debugged to continue execution. Typing 'quit' quits the program :P
// posted by Matt Fleming @ 11:34 pm 
Subscribe to Posts [Atom]