Hi All,
I want to share my recent experience with debugging a code.

Task
I was processing about 500 files through a code that I had refactored extensively.

Problem
I noticed that while most of the files were parsed as expected, about 50 files were much smaller than the expected filesize. I tried rerunning the missing records through the parsing script and it produced the expected result! This was driving me crazy.

Solution
I then used a Perl debugging tool on the original file and ran the script step by step to see why I am getting a smaller file. The culprit was this line in some 500 lines of code:
if( $variable > $certain_value) { exit; }
While this works for most of the files where this condition is not satisfied, certain files do meet this criteria and hence the script exits prematurely!
When I changed this to skip to the next record, it worked like a charm!
if( $variable > $certain_value) { next RECORD; }
Lessons Learned
Even if it takes time to run a script line by line using the debugger, spend this time to save your sanity!

Replies are listed 'Best First'.
Re: How a baisc debugging effort restored my sanity!
by Anonymous Monk on Feb 23, 2011 at 00:02 UTC
    Lesson Also Learned

    Don't bury exit deep in your subroutines; use next/last ... then return out of your subroutine, then exit your program

    use MyStuff 'MyThingWhichUsedToExitButNowReturns'; exit MyThingWhichUsedToExitButNowReturns();
      For this deep-in-the-code stuff i usually use croak. Especially for one-off stuff that *probably* no one but me will ever use. This raises awareness of the problem, without having to implement a gazillion of error handling stuff beforehand for software that's only meant to be run by the developer him/herself.
Re: How a baisc debugging effort restored my sanity!
by vkon (Curate) on Feb 23, 2011 at 17:51 UTC
    yes, ptkdb is a real cool, it rocks sooo much!
    Actually it is a bit pity that it is not used quite often

    me - I used it couple years ago, now I almost do not use it, only very very occasionally.

    You must be careful sometimes - when you move mouse over variable that expands into large structure - it could eat all memory and thus hung.
    but this is quite easy to cope with.

    And I happen to reorganize it into Devel::tcltkdb, it uses Tcl::Tk which is a modernized perl/Tk.

    And also I plan to rename tcltkdb to just 'tkdb' at next release.

    Regards,
    vkon

      Tcl::Tk might - in your opinion - be a modernized perl/Tk, but it doesn't build on any platform, which makes it quite useless to start with.

      I also browsed google to find if someone posted a fix for the failing prereq in Tk, but the suggested "tklib" is not available on my Linux distribution.

      I must also add that Tk is very actively maintained by Slaven Rezić. At the moment I post this, the last commit was done on 2011-02-24 23:18:56, less than a week ago.


      Enjoy, Have FUN! H.Merijn
        all those CPAN reports are bogus and useless - pick any of those:
        ------------------------------ PROGRAM OUTPUT ------------------------------ Output from '/usr/local/bin/perl5.13.10 Makefile.PL': no display name and no $DISPLAY environment variable while executing "load /usr/lib/libtk8.4.so.0 Tk" ("package ifneeded" script) invoked from within "package require Tk" (file "test-for-tk.tcl" line 1) Your Tcl installation (tclsh) fails to find Tk package.
        What use of smoke report without underlying library?

        Also, Tcl::Tk, Tkx and Tcl CPAN packages have mailing list where you could have your questions answered.

        perl/Tk development is something that is not very inspiring me - Slaven is doing number of efforts and this is certainly deserves much of a respect - but this is mostly wasted efforts, because most of this code is already available in tcl/tk itself.

        okay, I think I should take more care of those bogus reports from testers

Re: How a baisc debugging effort restored my sanity!
by GotToBTru (Prior) on Mar 09, 2011 at 21:32 UTC

    I just 'discovered' the debugger a few weeks ago, thanks to perlmonks, and have made regular use of it since. I knew there was some sort of debugging capability, but I thought using it involved installing modules and writing stubs.

    I have emailed copies of the debug tutorial and the full documentation to my coworkers, many of whom were also unaware of the quality of this facility. I know it will be used, because our code is liberally sprinkled with:

    #print "Okay, I got this far!\n";