Monday, April 5, 2010

Fixing a real bug with the help of Winpdb

Over the last few years as I have gotten more and more addicted to programming Python, I have basically stopped using debuggers. This is not because I write bug free code, but because I prefer not use any of the IDEs available for Python, and I really don't much get along with pdb. I have always found that I need to invest a lot of effort into pdb to get what I want from it, and so now I default to "print line" debugging (using print statements to dump state to the console).

A couple of days ago, I decided to look into graphcial debuggers. I tried some of the Python IDEs out there, and they just really weren't for me. I saw Winpdb in the repositories, and decided to give it try. Today I have a bug that was a good test case for it. I imaging that I will be adding Winpdb to my toolkit on a more regular basis now.

The Bug
Over the weekend didrocks update quickly-widgets in universe for me. quikly-widgets provides the DictionaryGrid class, that I use in bughugger to display data from bdmurray's JSON searches. I check bughugger every morning to see what the desktop team is working on, and generally where we are in terms of the bugs assigned to use.

So when I run bughugger this morning, I saw this:


Oops, only columns. Obviously a bug in quickly-widgets broke bughugger, but where?

Starting the Debugger
So I fired up the Winpdb. First thing is to select the file to launch. So I choose File -> Launch, and navigate to the bin/buhgugger file. I select a line close to, but before where I want to break the program. Clicking in the channel there, are using F9 key, sets a breakpoint. The run button then runs that app and will stop at the first breakpoint it hits in the source.





Debugging
After stopping at the first breakpoint, I see that I need to set a breakpoint in the add_*_triage_page functions, as that's where bughugger starts to assemble the view. The "keys" variable determines what columns are created in the DictionaryGrid, so I decide to watch the keys get passed around. I can see that the keys are set correctly here.


I use "run to line" and "step into" to see that the keys are still correctly set at when BugsPane is being created.
So I run to where the DictionaryGrid is created. The fact that I depended on the order of arguments instead of using keywords looks a bit suspicious to me.


So I step into the constructor for the DictionaryGrid, and see that, in fact, I did change the order of the contructor parameters, so it's not surpriisng the app went a little haywire. I fixed the bug by changing the call to use keywords.
I think using Winpdb saved me tons of time and effort compared to using pdb, or print statement debugging. In any case, it was a matter of minutes to find this bug, do I could go on to fixing the next bug :)

2 comments:

  1. Hey Rick, thanks for this great article.

    I always ran into trouble using debuggers, though I believe it's a tool you really have to learn to use as a software developer.

    ReplyDelete
  2. When people think of sex, they often think of orgasm as the ultimate way to achieve pleasure. (Playmates Porn movies Models with their experimenting sex positions). Female orgasm, in particular, is often seen to be proof of sexual success. To achieve High-end Sexual Arousal - visit
    Porn Movies and Videos
    XXX Sex HD Videos
    Wild Porn Movies

    ReplyDelete