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

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

Sunday, July 09, 2006

Tim Peters' current-frames branch

Tim posted a message to python-dev today asking if he could get some changes into the threading code of Python, namely, exposing a mechanism for mapping thread names to thread frame objects in a dict. This is the original conversation back in March 2005, http://mail.python.org/pipermail/python-dev/2005-March/051856.html.

Since the Python trunk is in "feature-freeze" and Tim's patches can't be incorporated, it looks as though he's made his own branch for these features, tim-current_frames. The actual code is going to be used to get the functionality of a module called 'threadframe' into the Python core. This could really be useful to my SoC project for using these features to help debug threaded applications :-) Who knows, if I can think of some useful things to add, maybe Tim will accept them?

I'll keep y'all posted.

Tuesday, July 04, 2006

Non-Soc related post.

Well yesterday one of my lecturers at university emailed me to tell me that he's changed my degree programme to computer science from computing, which was at my request. This is a good thing for me a) because computer science has much more interesting classes than computing b) I would have wasted option-points choosing comp sci classes and would still have had to do the boring computing classes! So, all in all, I'm a happy man..

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]