Unraveling Code with the Debugger
by Daniel AllenApril 06, 2006
To mangle an old saying, with apologies to Sartre, "Hell is other people's code." Other people think differently than I do; they use weird idioms, and sometimes their comments are incomprehensible. Invoking the debugger on someone's code is like having a conversation with the author. It opens the code to the questions I want answered, in real time--and there's another party in the conversation, the Perl interpreter. The debugger makes it easy to try things out, even quicker than writing a one-liner, because the environment's already set up for the running program.
This article is a case example of using the Perl debugger in a production environment. In this situation, we had problems with CGI scripts on a machine I don't maintain. I wanted to go in, solve the problem, and get out quickly, without unnecessarily changing anybody's code.
I've written the article so that you can follow along yourself, if you wish. To do so, you need a Linux/Unix system with Perl 5.8, Apache (any version), and a basic TWiki installation. (I'm using version 20040902-3.) TWiki is quite easy to install from packages; it took me 3 minutes under Ubuntu, including answering a few installation questions. If you're installing for this walk-through, enable the sample data set, which installs into the default TWiki directories (/var/lib/twiki/data and /var/www/twiki/pub on Debian and Ubuntu).
Additionally, for any use of the debugger, you should install the Perl modules Term::ReadLine and Term::ReadKey from CPAN. These will give you bash/csh-like cursor control, history browsing with up and down arrows, and tab completion on variables and functions.
Statement of the Problem
Our production installation of TWiki had a problem with a hidden web: a section that users could reach only by using its URL, rather than through the usual list of public webs (on the left side of each page). The problem appeared when we tried to make the hidden web public; it remained hidden. We lived with this for a few weeks, convinced that TWiki had a sticky setting somewhere that we didn't know about, or perhaps TWiki had a bug. The documentation, while excellent, didn't seem to address our problem. A number of people looked at the configuration files without seeing the solution.
Above all, it was important to fix this quickly, because we couldn't spend much effort on this relatively minor annoyance. We were almost at the point of asking for help within the TWiki community, but as we didn't find evidence anybody else was having this problem, it likely wouldn't be a quick fix. (As you're reading, you may see the answer, but please keep reading; the utility of the debugger extends far beyond such an easy problem.)
Initial Look
To create a hidden web within TWiki, set NOSEARCHALL = yes in the web's WebPreferences page. Setting NOSEARCHALL = no still left the web hidden.
The documentation suggested that the only configuration variable involved was NOSEARCHALL. My next step was grepping the data directory, and then the TWiki source code--which turned up the likely code responsible, a certain function TWiki::getPublicWebList. Looking at that code didn't make the answer clear. (If you're following along, go ahead and run perldoc -m TWiki to see if you can spot the problem by inspection.)
Back in the web browser, I noted that the URL for normal TWiki page viewing was http://hostname/cgi-bin/twiki/view/Main/WebHome.
From my initial look at the code, I knew the CGI that produced this was in /usr/lib/cgi-bin/twiki/view. Could I run it from the command line? Changing to that directory, I ran ./view and saw the expected HTML for the front page.
|
Related Reading |
