ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

Platform: sparc solaris 9, perl 5.6.1

I'm maintaining an inherited multi-thousand line legacy application
server with minimal documentation (three strikes already against
me...).

The server implements an ascii interface language that gives
applications search and update access to an internal database of
information.

As the server parses a specific command, it uses perl soft references
to determine what subroutine of what perl module should be invoked.

All of its operations are performed in this fashion.

When one particular type of command is being parsed, the error
"Undefined subroutine &Policy::remove_request called at Server.pm line
10346.

In Policy.pm, a subroutine called remove_request does in fact exist.

Other subroutines in that file are found without problem.

None of the subroutines are explicitly exported or imported. But for
some reason, this particular function isn't being seen.

Policy.pm and Server.pm do include a "use strict" statement.

I'm wondering if anyone has found other tools to be of use in
determining why some subroutine in a file might not be seen.

To me, at face value, this explanation doesn't make much sense - why
would perl complain about this subroutine but not others.

I'm working on adding some additional print statements to try and
verify that this is the only subroutine that is failing in this
particular statement.

Any other ideas of what could be checked would be appreciated.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

[A complimentary Cc of this posting was sent to
lvirden
], who wrote in article <1194632891.033609.193940@v2g2000hsf.googlegroups.com>:
> When one particular type of command is being parsed, the error
> "Undefined subroutine &Policy::remove_request called at Server.pm line
> 10346.
>
> In Policy.pm, a subroutine called remove_request does in fact exist.

Can you *check* that it exists/defined at the beginning of execution (after
all the modules are loaded)? Can you explicitely check that it does
not exist/defined immediately before this unfortunate call?

If yes on both counts, all you need to do is to find out when it
disappears. E.g., use 'watch' in debugger...

Hope this helps,
Ilya

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On Nov 11, 8:43 pm, Ilya Zakharevich wrote:
> ], who wrote in article <1194632891.033609.193...@v2g2000hsf.googlegroups.com>:
>
> > When one particular type of command is being parsed, the error
> > "Undefined subroutine &Policy::remove_request called at Server.pm line
> > 10346.
>
> > In Policy.pm, a subroutine called remove_request does in fact exist.
>
> Can you *check* that it exists/defined at the beginning of execution (after
> all the modules are loaded)? Can you explicitely check that it does
> not exist/defined immediately before this unfortunate call?

Hmm. I'm uncertain how to determine that code that is explicitly coded
in a file exists or not.


>
> If yes on both counts, all you need to do is to find out when it
> disappears. E.g., use 'watch' in debugger...

I haven't quite figured out how to get debugger to run on this piece
of code - there are time critical parts that are likely to fail, and
there are so many lines of code that it would be pretty tough to
monitor it.

Obviously I have a LOT of perl that I need to learn. Thanks for the
idea though - I suspect that finding out how to check when the soft
references exist or not is a good place to investigate.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On 2007-11-12, lvirden wrote:
> Obviously I have a LOT of perl that I need to learn. Thanks for the
> idea though - I suspect that finding out how to check when the soft
> references exist or not is a good place to investigate.

Just a thought, but have you triple-checked that the spelling of the
subroutine name is correct? Maybe it exists, but it's called with the
wrong name, say renove_request rather than remove_request?

C

--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On Nov 12, 9:03 am, Claudio Calvelli
wrote:
> On 2007-11-12, lvirden wrote:
>
> > Obviously I have a LOT of perl that I need to learn. Thanks for the
> > idea though - I suspect that finding out how to check when the soft
> > references exist or not is a good place to investigate.
>
> Just a thought, but have you triple-checked that the spelling of the
> subroutine name is correct? Maybe it exists, but it's called with the
> wrong name, say renove_request rather than remove_request?
>

Yes, I've checked over and over on the spelling.

In Policy.pm , I have the line:
sub remove_request

which starts the piece of code in question, and in the parse table, we
have:
'=' => ['remove_request', 1],
'=' => ['remove_request', 1],
'=' => ['remove_request', 1],
'=' => ['remove_request', 1],
'=' => ['remove_request', 1],
'=' => ['remove_request', 1],

and then later:
my $what = 'Policy::' . ${$where->{$word}}[0];

and finally

eval { no strict 'refs'; &{$what}($self, @chunk[1 ..
$args]); };

which results in the error:


Undefined subroutine &Policy::remove_request called at Server.pm line
10347.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On 2007-11-12, lvirden wrote:
> In Policy.pm , I have the line:
> sub remove_request
[...]
> which results in the error:
>
> Undefined subroutine &Policy::remove_request called at Server.pm line
> 10347.

Another thought is that there is a "package something" somewhere before
the sub remove_request, so it isn't in package Policy?

Yet another thought is that the "sub remove_request" may not be actually
followed by a block... but I'm sure you'd have noticed that.

You may find useful to print keys %Policy:: (not trailing :: - the package's
symbol table, or whatever is called in the documentation) and comparing the
output with the list of subroutines which should be defined by package Policy -
see if remove_request is there, and if anything else you expect to see but
is missing.

I must say this all looks weird.

C

--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On 2007-11-12, Claudio Calvelli wrote:
> You may find useful to print keys %Policy:: (not trailing :: - the package's
That should have been "note trailing ::"...

C

--
The address in the "From" header won't work. Email to "usenet" at "intercal" dot
"dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages
to go through the spam filter, and other conditions which I won't disclose.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

On Nov 12, 12:28 pm, Claudio Calvelli
wrote:

> Another thought is that there is a "package something" somewhere before
> the sub remove_request, so it isn't in package Policy?

I really appreciate your ideas. I checked after reading your msg - the
only package something in Policy.pm is the
package Policy;
statement.


>
> Yet another thought is that the "sub remove_request" may not be actually
> followed by a block... but I'm sure you'd have noticed that.

sub remove_request
{
:
Perl code here
:
}

is there in the file, so there's a block.

>
> You may find useful to print keys %Policy:: [...] and comparing the
> output with the list of subroutines which should be defined by package Policy -
> see if remove_request is there, and if anything else you expect to see but
> is missing.

Thanks - I'll try that next.

>
> I must say this all looks weird.
>

Yea - to someone who's trying to keep this system going, it looks very
weird as well.

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

Okay, here's what ended up being my problem - just in case someone
else comes along with the same thing.

Printing out the key %Policy:: showed me all the sub's except for the
one I was trying to get. I looked at the sub (see last msg) and there
was a block after it.

BUT

Here's the gotcha. The person who had coded the module had written

=item I(\Server, $comment) undef

sub remove_request
{

Perl novice that I am, I didn't notice the missing "=cut" in the file!
Sigh.
Something so simple - and I've been beating my head over this one for
a long time.

Thank you so much to Ilya Zakharevich and Claudio Calvelli for their
contributions!

Re: ISO: deep voodoo debugging tools for tracking down seriously weird module behavior.

[A complimentary Cc of this posting was sent to
lvirden
], who wrote in article <1194873702.603490.82100@o80g2000hse.googlegroups.com>:
> On Nov 11, 8:43 pm, Ilya Zakharevich wrote:
> > ], who wrote in article <1194632891.033609.193...@v2g2000hsf.googlegroups.com>:
> >
> > > When one particular type of command is being parsed, the error
> > > "Undefined subroutine &Policy::remove_request called at Server.pm line
> > > 10346.
> >
> > > In Policy.pm, a subroutine called remove_request does in fact exist.
> >
> > Can you *check* that it exists/defined at the beginning of execution (after
> > all the modules are loaded)? Can you explicitely check that it does
> > not exist/defined immediately before this unfortunate call?
>
> Hmm. I'm uncertain how to determine that code that is explicitly coded
> in a file exists or not.

"in a file" is absolutely irrelevant. To check whether a subroutine
foo::bar() is declared/defined, use
exists &foo::bar
defined &foo::bar

Hope this helps,
Ilya