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 ;).

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?

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?

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));
[download]

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);
[download]

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));
[download]

poj

AA.pm
use strict
use warning

  sub Abug1 {}
  sub Asub2 {
      BB::Bsub1(1,2,3);
      BB::Bsub2(hostname);  # hostname is a "bareword"
}
  sub Asub3 {}
[download]

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 AA.pm

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

"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 AA.pm", which is:

Bareword "CA_list" not allowed while "strict subs" in use at AA.pm line 309. BEGIN not safe after errors--compilation aborted at AA.pm 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.