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

I have 2 perl modules, calls I added a new call in to sub Abug1 sub Asub2 BB::Bsub1 BB::Bsub2 sub Asub3
I added the call to BB::Bsub2 It compiles with out any warning or error. It executes ASub2 just fine and works. The problem is that Asub3 seems to no longer be defined when the call to BB:Bsub2 is present. When I try to access the web page that is served up by AA::Asub3 the error reported is:

Error executing run mode 'Asub3' : can't locate object method 'Asub3' via package "AA::Aa" in ... perl\site\lib\CGI\ line #143

I launched the program under the debugger and listed the present subroutines with "S AA". When the call to BB::Bsub2 is present, the AA::Asub3 doesn't show up. Remove the call to BB:Bsub2 and in the debugger "S AA" shows AA::Asub3 and everything works fine.

This is running strawberry perl v5.12.1.0 on Windows. Any pointers on how to debug this very much appreciated.

Replies are listed 'Best First'.
Re: CGI::Appl can't find sub
by davido (Cardinal) on Jun 10, 2014 at 17:49 UTC

    I suggest boiling the problem down to a 20-line-or-less example that uses real code, and that we can run to see the behavior you're experiencing. It's possible that in doing so you will have removed enough distractions that the problem and its solution become plainly obvious, in which case you won't need further help.

    Even if that doesn't lead you directly to an obvious solution, it will provide us with something concrete to assist in debugging. Your current problem description lacks anything we can actually look at to say, "Oh, it's because of xyz. Try abc." And by boiling it down to a small test example it relieves us from the tedium of skimming through a couple hundred lines of irrelevant code to find the relevant parts ourselves (that's your job ;).


Re: CGI::Appl can't find sub
by boftx (Deacon) on Jun 10, 2014 at 17:52 UTC

    Is it possible you introduced a subtle syntax change/error when you added the new call? That's what it sounds like given your (very) sparse description. On a related note, you do have strictures turned on, right?

    You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.
Re: CGI::Appl can't find sub
by TomDLux (Vicar) on Jun 11, 2014 at 06:02 UTC

    It seems likely that adding the subroutine call altered the scope of Asub2. Perhaps you deleted a closing curly brace or a semi-colon?

    Are you using warnings and strict? What does perlcritic say? When you use perl-tidy, is Asub3 indented the way you think it should be?

    If you aren't using these tools to analyze your problem, is there a reason for skipping them?

    As Occam said: Entia non sunt multiplicanda praeter necessitatem.

      Thanks for the feedback. There are 4 perl modules with 3500 lines of code that I'm not familiar with. I have tried disabling various pieces, but there are many dependencies. I'll take another pass at minimizing the code.

      I am using strict and warning. I added "use B::lint". I also tried "perl -MO=Lint,all myprogram". Thanks for suggesting perlcritic. I wasn't aware of that. It did not turn up anything that seems significant with a warning level of 3. I might try a more detailed pass.

      Here is the single line, that when commented out everything works fine:

      my $ret2 = &CCC::DDD::setCAlist($self->param(CA_list));

      The subroutine it is in already had the following call just a few lines above the line I added and everything works fine.

      my $ret = &CCC::DDD::init($cfg_file,$repfp,0);

      I was hoping that someone had seen this exact error in a similar calling scenario or suggestions on additional tools and debug methods. I didn't expect a full analysis given only an outline. It seems like a syntax or scope issue in existing code, not a problem in that one line to call CC::DD::setCAlist(), but I am new to perl.

        I'm guessing that maybe init is a constructor returning an object. If it is then you should probably be calling setCAList as a method like this.

        my $ret2 = $ret->setCAList($self->param(CA_list));
Re: CGI::Appl can't find sub
by jimt999 (Initiate) on Jun 13, 2014 at 21:41 UTC
    I have determined the cause of the problem. Here are more details to the calls made for the problem seen when adding a new call in to use strict use warning sub Abug1 {} sub Asub2 { BB::Bsub1(1,2,3); BB::Bsub2(hostname); # hostname is a "bareword" } sub Asub3 {}

    Asub2() is only invoked at runtime via CGI::Applicaton run_modes(). The problem is that with "strict" enabled, barewords are not allowed as parameters to subroutine calls. Instead of reporting an error, the compilation is quietly aborted in the *next* subroutine when a single quote is found: resulting in all subsequent subroutines not being compiled. It also results in the program running for code that compiled and the offending subroutine working just fine. I could see that the other subroutines were missing in the debugger, I just couldn't figure out why. The key was running:

    perl -MO=Terse

    It reports the offending line and where compilation is terminated. I'm glad I ignored the module description I found on

    "This module is useful for people who are writing their own back end, or who are learning about the Perl internals. It's not useful to the average programmer."

    I expect that this is an unusual case because:

    1. The resolution of the function doesn't occur until the specific web page is selected and is done as a string lookup.

    2. The invocation of the subroutine is protected in "eval { }" so the program keeps on running.

    Thanks for the input and I hope this can help someone in the future.

      The problem is that with "strict" enabled, barewords are not allowed as parameters to subroutine calls Instead of reporting an error, the compilation is quietly aborted in the *next* subroutine when a single quote is found

      barewords don't have that effect, they're not magic

        Okay, then please explain the output from the "perl -MO=Terse", which is:

        Bareword "CA_list" not allowed while "strict subs" in use at line 309. BEGIN not safe after errors--compilation aborted at line 423.

        Note that line 423 is about 15 lines into the *next* subroutine after the one with the bareword parameter. Adding double quotes to the parameter fixed the problem. What made this so hard to root cause is that the problem did not cause the subroutine with the problem to fail. The error message also corresponds with what was observable in the perl debugger - "S AA" failed to show any subroutines after the one that contained line #309.