pjbrenner has asked for the wisdom of the Perl Monks concerning the following question:

I am mantaining a perl program for a client that I did not write. It is a fairly complex program but the jist of it is that is listens on a socket and responds with an appropriate message. The program is failing with a message like: "Can't call method "format" without a package or object reference at (eval 71832) line 1." The problem is that the program is failing in their production environment and I have no idea where is the program. The real question: Is my only choice for debugging the program is to bring it up in the debugger with "perl -d" or is there some other way of debugging a perl program. I cannot put print statements in because the program is to large and I don't yet know where it is failing. Any help would be appreciated

Replies are listed 'Best First'.
Re: Debugging Perl Program
by Ovid (Cardinal) on May 20, 2002 at 17:04 UTC

    pjbrenner wrote:

    I cannot put print statements in because the program is to large and I don't yet know where it is failing.

    Personally, I find that the size of a program is usually irrelevant to finding out where to put print statements for debugging. I trace the program flow and essentially use a binary search to narrow down where to put the print statements.

    A simple example: for 500 lines of code, I put a print at 250. Does the program die before it? I put the print at 750. A binary search quickly narrows down where the problem is.

    For your error message, it sounds like you may have an object instantiation that is returning undef, or an unblessed reference. grep the code base for the word "format" and see how your program might be trying to access the appropriate code.

    Cheers,
    Ovid

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
Re: Debugging Perl Program
by broquaint (Abbot) on May 20, 2002 at 16:59 UTC
    This sounds like it could be due to the evils of indirect object methods. Firstly make sure that the format() method is being called from an existent object e.g 
    # this should create an object to work with
my $obj = Some::Module->new();
   # call the format() method on the $obj object
   $obj->format();

    [download]
    I don't think you really need to go into a debugger at this stage, especially with such a nice and descriptive warning message (which is further explained in perldiag). Perhaps if you just brushed up on your perl skills or read a couple of man pages[1] then you could crack the case of the missing object.
    HTH

    _________
    broquaint

    [1] check out Masem's excellent How to RTFM for further info on how to take advantage of perl's extensive docs

[reply]
[d/l]
Re: Debugging Perl Program
by particle (Vicar) on May 20, 2002 at 17:31 UTC
[reply]
Re: Debugging Perl Program
by graff (Chancellor) on May 20, 2002 at 18:51 UTC
    Using "perl -d" on the script shouldn't be a problem, and there's every good reason to use it as a first resort, so long as you establish some good places to put breakpoints before you start execution. Let me embellish Ovid's advice a bit; if you're on a system with an "egrep" command, just do: 
    egrep -n 'eval|format' your_script.pl

    [download]
    or if you don't have egrep (well, get it -- the gnu version is available for MS Windows), you could use a command-line perl script to the same effect: 
    perl -ne 'print "$. $_" if (/eval|format/)' your_script.pl

    [download]
    Anyplace where "format" follows closely after "eval", use the line number of the "eval" to set a breakpoint in the debugger (using the "b" command).

    When using the debugger, I find it helpful to have the script also loaded in a text editor that allows going to specific line numbers easily.

    If this is a cgi script, you'll either need to set $ENV{QUERY_STRING} to some suitable value before starting execution, or else you may want to "enhance" the script a bit so it can get the query_string args from ARGV if $ENV{QUERY_STRING} happens to be empty. UPDATEHaving just seen that you have multiple source files to work through, exend the egrep to all source files, and also find the names of subs or objects in the "main" script that reference the other sources, and put breakpoints on those names, so that when you "step" into those calls, you can then set line-number based breakpoints within those other source files. Okay, so there's more prep work before actually starting execution in the debugger, but it's still likely to be the shortest path.

[reply]
[d/l]
[select]
Re: Debugging Perl Program
by pjbrenner (Initiate) on May 20, 2002 at 17:16 UTC
    One of the problems is that their are 5 different "format" subs in the program spread accross multiple packages. A lot of objects get instantiated in this program. If I need to debug this program am I left with using "perl -d"? I can't install anything else on the box so I only have the default debugger.
[reply]

Back to Seekers of Perl Wisdom