Breaking the Perl Debugger for Fun and Profit
Before I cover the main topic of this entry, here are some short news and action items:
-
If you have not acted against SOPA - the proposed online blacklist/censorship bill, you should. Follow the link for information on how to act against it.
-
I have announced the next Tel Aviv Perl Mongers meeting on my technical journal on LiveJournal.com. It will take place this Wednesday, on 28 December, 2011. More information in the link.
-
Anarchy Golf is a new server for Code Golf, which are online programming competitions for implementing code as shortly as possible. It supports Perl 5, Perl 6 and many other languages. There is an active challenge, where the only Perl 5 submission so far is mine, so I could use some competition.
Now for the main topic of the post. Recently, three patches were integrated into the perl-5 core implementing new features in the perl debugger:
- Add "b <filename>:<line> <cond>" to perl -d by me.
- Add enable/disable commands for breakpoints in perl -d also by me.
- "Trace to max depth" by Peter Scott.
When Father Chrysostomos tried to apply the first patch, he noticed its tests started failing. Apparently, the breakpoint functionality (irrespective of the patch's added functionality) became broken in bleadperl, due to a change in the internals, and it wasn't caught by the debugger's existing tests. I ended up submitting another patch to add a test for some of the existing breakpoint functionality.
The other two patches passed all of their own tests and the existing ones, but that wasn't the end of the story. A short time afterwards a regression was reported in the debugger, which was caused by one of the patches that I introduced. While, I fixed it with a test, it was soon followed by other reports and fixes. None of these bugs were caught by the test suite of the perl debugger, which is incredibly incomplete.
Another E-mail that caused an active discussion was my proposal to add strict and warnings to lib/perl5db.pl, in which someone kept arguing against it, and eventually said he confused it (it being the defualt command-line debugger front-end) with the debugger's guts, and ended up also supporting adding "use strict;".
I ended up working on adding "strict" to the debugger on a git branch, and was eventually successful (though I temporarily broken no-strict code on the debugger evaluated lines, to which I added a test.). RJBS (the current pumpking) said he'd like to integrate this patch only after perl-5.16.x is released.
The morals of this story is that the perl debugger needs more tests, and that trying to enhance it can easily break it. I started a branch on GitHub where I've been committing more tests to the perl debugger to enhance its coverage.
There's also a Google Code-In task for devising a strategy to do that, and I've volunteered to mentor it. All this will hopefully result in less breakage in the future.
Happy Holidays, and a Happy New Year.
An Israeli software developer, essayist, and writer, and an enthusiast of open/free software and cultural works. I've been working with Perl since 1996.
The breakpoint in a different file feature was something that I've always thought that it is somewhere and I only don't know how to invoke it - which always frustrated me. Thanks a lot for implementing it :)
zby: you're welcome, and there was (and still is) indeed a way to do it previously by switching the active source file to a different one and then setting a numeric breakpoint, but it was counter-intuitive, and I don't recall the specifics.